Inlineing and multiple naming of function

[RIGHT_THEN]

GentleMen

i propose that Cobra should support inlining with inline keyword
althou small functions are automatically inlined by CLR and c++ inline
is left upto the compiler to decide if atall inlining should be done or not inline is considered a suggestion to compiler that that is what our
intention is

i wish this becomes expicit in cobra by specifying inline that compiler
must inline certain function.it would be further benificiall if sometimes we want that inline function should not be inlined at some place than we could specify there.

def inlinedFun has CobraInlineAttribute
    pass

while using/calling

.inlinedFun # gets inlined
.inlinedFun [CobraDontInlineAttribute/keyword/something to enable this feature] #this would not
                                                                                #inline

or evenbetter
even when one has not applied CobraInlineAttribute to a function
if one would put

.inlinedFun [CobraInlineAttribute/keyword/something to enable this feature] #this should 
#inline it right
#there

and also one thing i have fancied for sometime is multiplenames for functions to clear the logic

for instance i as a developer make a function that gives something
like sendName() i am sending the name through this function
when user uses it from my library he should be able to see getName()
because according to him he is Getting the name not sending but i am
sending so it is logicall for me to name it sendName() and logical for
User to see as getName().

althou this example tries to present the essence of what i think
whereas actually one can merely name it as name() but there are other
situations where we are not trying to convey name throught function

if it happens codes of both user and developer would make sense reading
when one wants to comprehend it. it makes the intent clear

Developer writes
--------------

def sendName()
   # name is clear what it wants to do
   pass

client Uses
-----------

Code: Select all

Somelibrary.SomeClass.getName()
  # makes sense
 Somelibrary.SomeClass.SendName()
  # does not makesense

so for this a attribute can be made
CobraAliasFuncNameAttribute which applies mutilple times
which might be used like this

Code: Select all

[CobraAliasFuncNameAttribute(getName)]
 [CobraAliasFuncNameAttribute](anynumber of other possibilities..)]
 public string sendName()
 {

 }

whereas at the code generation level cobra could just be passing control to same function like.

Code: Select all

 [CobraAliasOfFunction(sendName)]
 public string getName()
 {
   return sendName()
 }

all it does is takes away the load of creating mutiple functions from
user to present his intent and throws on the compiler to generate it
for him.


i hope i have conveyed what i wanted to convey rather than creating
confusion.

with multiple naming and other things many possibilities arise to present
our intent.

THANKING_YOU
RIGHT_THEN

[Charles]

Regarding inlining, I'm not opposed to it, but Cobra is already pretty fast and inlining will probably never hit my short term "to do" list. Also there are other approaches to speed up your software such as profiling, caching, simplifying calculations, etc. many of which are generally more profitable than explicit inlining.

Do you have an application or problem for which inlining would make a difference to the end user?


Regarding method aliases, I would find it confusing to see two or more names for the same method. Also, if you are uncomfortable with common naming practices for methods then I think you just need more time and practice with object-oriented programming (OOP). It is a mindset and there is a learning curve, but once acquired, it works well.

When I first studied accounting, I found some aspects of it non-intuitive. The solution was to keep at it until it made sense due to learning how the whole system of elements and rules worked together.

Regarding naming, I rarely use "get" and "set" prefixes. Instead, these are done as property (or method) names such as "color", "age", "maxLimit", etc. These names make sense to both the implementer and the caller. Most of the Microsoft libraries follow this pattern, but then they confuse people with their use of GetType, GetHashCode and other methods in some of their earliest classes.

Then for methods I use the form "verbDirectObject" such as "bindInterface", "computeSomething", "checkFoo", etc. There are some other conventions. Maybe I should write up a wiki page on the subject.

HTH

[RIGHT_THEN]

Charles,

let inlining be at minimal priority for you but do allow yourself to implement it sometime
cobra is fast than many, inlining used judisiously would only make it faster maybe beating c#
itself because how code reaches c# is in your hands.

as for senario i find i am reminded of a project that i did for myself once when i got
interested in stocktrading someyears back. thou am not now. in which i tried to implement
my logic to assess the period for trade specially in day-trading. hundered of stocks history was
to be presented to analyse and present their moment in respect to the historical moments they
have made. so calculations were enormous and same functions were being called again and again.
now i have never worked professionally on any project ever and dont intend to this is not my profession just a passion sometimes. at that time i thought of inlining because doing inlining
manually makes code hot-potched and refactoring also becomes combursome, at how many place would one inline manually.

in such conditions i thought that not only inline keyword is required but also the option
to not inline it because inlining would certainly bloat the code.inlining option should be in a way that it could be allout inlinging as well as restricted where we want it to be.

Now regarding multiple names i know about properties and GetName() SendName() were merely intended
to convey my idea/intention.but downunder even properties are functions only. Try to access properties of c# in c++/CLI they are getName() setName() you wont be able to see name()[*]

and C++/CLI produces more optimised code than C#.[*]

i would agree that i certainly require much more practice to convey my intent as others might have
aquired over the years. but while you are trying to write your programms and when using
your variables,props,functions, whose names seem quite allright to you and while using them in
certain statement you wished if i could write it this way here althou the functionality would still be the same. remember than that that is what i might have been trying to convey.

on second thought Inlining could be benificially in apps for
1) accounting
2) heavy calculation
3) genetic programming and chemical analyses ( i hear they often are done on supercomputers
Sombody please tell them they ought to use Inline keyword thats it)
4) you yourself know of many examples

Thanking_You
RIGHT_THEN

[*]i do not adamantly contest for those points and will accept correction

[Charles]

Thanks for the comments. It's interesting that you brought up a stock trading system from years ago. That's the last personal project I worked on, in both C# and Python, before I became fed up and decided that programmers needed something better.

Btw I now recall that when I had once considered inlining for Cobra, I had discovered how tough it would be in the .NET (and JVM) environment. Consider a method that accesses protected variables. You cannot put that code inline in a different class because there is no way to access the protected vars. Although as you say, I "will accept correction."

If the target were C instead of C#/.NET or JVM, it would be easier.

[RIGHT_THEN]

Charles

i dont know of other instances that might be hindering Inlineing but as for private members they can be accessed. i have read it in a book
that i dont recall but knowing it can be done i googled and just two links might inspire.

http://stackoverflow.com/questions/1965 ... a-variable

http://stackoverflow.com/questions/2258 ... s-subclass

anyway it indeed would be difficult for you to implement such things
because you would have to ascertain what all is being used in a
function to be inlined and then generate accordingly.

Reflection approach or c#`s approach what it does to implement closures/lambdas/delegates could also come into play i think they capture
the values inside of a function that might be used in a closure by creating a proxy variable outside of that function and then reference it
when required even when control has gone out of scope from the function
that had closure working in it that used its private variables.

similarly cobra could figure it out and then implement the logic to make
it work.

Thanking_you
RIGHT_THEN