There's actually quite a big difference between calling methods and sending messages
popycock. it's a syntactical difference, nothing more.
certainly, c++ and objective-c have different binding requirements, but that has absolutely no bearing on syntax. anyone who tells you different is just making excuses for bad decisions made long ago.
Windows install = OS. Applications (office suites, servers etc) need to be purchased and installed separately.
Linux install = OS + full working set of applications.
Try comparing like with like.
wait, which office suite that's available for free on linux needs to be purchased on windows?
actually, i can't think of any major linux applications that aren't either also available for windows themselves, or are easily substituted for some other freely available windows app.
Like jcr said, you aren't calling methods, you are sending messages to objects.
and the difference is, exactly?
look, you're writing down somewhere what you're currently doing, and then passing some arguments to a function somewhere else. you can call it 'calling a method', or you can call it 'sending messages to objects'. semantically it's exactly the same thing. and it doesn't require a new syntax.
Why on earth does it hurt to name the parameters when you send the message?
it doesn't hurt (except for the pins), it's just unnecessary. sure, allow me to it when i think it might help clarity, but don't force me to do it all the time...
You can look at the code and know exactly what it does. When you type the code autocomplete kicks in and you know exactly what the method of the class is expecting. It's not like this stuff is new, the basics are nearly 30 years old at this point.
right, so you need a decent IDE to make it not a pain in the ass to write. nice. it's my belief that forcing the programmer to express the mundane and repetitive does NOT increase readability, or quality. conversely, if you allow the programmer to reduce the mundane, and hilight the exceptional, or unexpected you're much more likely to draw attention to those things and not have them lost in the all the noise.
I mean if you really want to go crazy you could say that none of the languages are unnecessary. Why would you ever use a pointer when you could just go to the address in assembly?
you're missing the point. i'm not saying there shouldn't be a way of calling methods (or passing messages to objects, or whatever you want to call it). I'm saying there doesn't need to be a completely new syntax invented for doing it when the existing one could have been minimally extended to support the new semantic requirements. they could have easily added smalltalk semantics to C without trying to bolt one language as an embedded DSL inside another in some frankenstein-type abomination.
sending messages, shmending messages, banana-ing function blobulators.
it's doesn't matter what you call it. it doesn't explain why there needs to be a completely different syntax for transferring control to a function that's bound to an object.
ok, so they added dot-notation property access after the fact. why didn't they also add dot-notation method access while they were at it?
i'm guessing they had a really good reason for adding the property access shortcut, probably something involving everybody telling them the old way sucked (see hot pins bit, above). and yet that pearl of wisdom didn't seem to make it as far as the method access syntax. shame.
sure, the new semantics are useful and nice. my problem is with the syntax. there's no need to create a completely new syntax for method calls, and there's no need to require naming parameters at the call site; they should have just added optional named parameters to the existing function call syntax.
for example: someFunction(value1, value2) myStruct.field myObject.method(value1, value2, optionalArg: value9);
it's not really better or worse, it's just unnecessary.
C already has a syntax for declaring and invoking functions, and it already has a syntax for accessing variables bound to instances of structs. why did they have to invent a completely new syntax for declaring and invoking functions bound to structs?
if "struct.field" is ALREADY a way or accessing a struct's field, and "function()" is ALREADY a way of invoking a function, then why can't "struct.field()" be a way of invoking a function that is a field of a struct? it's not that much of a stretch.
agreed. when i look at obj-c code it feels like someone's pushing hot pins into my eyes.
seriously.
why have (c-style) syntax for declaring and accessing variables and functions, and a completely different syntax for declaring and accessing bound methods?
it makes no sense. it doesn't add anything semantically to the language. it adds another syntax construct just for the sake of it. completely unnecessary.
and why are properties accessed using c-style syntax, and not methods?
none of the ms languages use all of the clr features. while c# and vb are getting closer over time, c++ and f# have significantly different requirements.
Slashdot Mirror
There's actually quite a big difference between calling methods and sending messages
popycock. it's a syntactical difference, nothing more.
certainly, c++ and objective-c have different binding requirements, but that has absolutely no bearing on syntax. anyone who tells you different is just making excuses for bad decisions made long ago.
Windows install = OS. Applications (office suites, servers etc) need to be purchased and installed separately.
Linux install = OS + full working set of applications.
Try comparing like with like.
wait, which office suite that's available for free on linux needs to be purchased on windows?
actually, i can't think of any major linux applications that aren't either also available for windows themselves, or are easily substituted for some other freely available windows app.
Like jcr said, you aren't calling methods, you are sending messages to objects.
and the difference is, exactly?
look, you're writing down somewhere what you're currently doing, and then passing some arguments to a function somewhere else. you can call it 'calling a method', or you can call it 'sending messages to objects'. semantically it's exactly the same thing. and it doesn't require a new syntax.
Why on earth does it hurt to name the parameters when you send the message?
it doesn't hurt (except for the pins), it's just unnecessary. sure, allow me to it when i think it might help clarity, but don't force me to do it all the time...
You can look at the code and know exactly what it does. When you type the code autocomplete kicks in and you know exactly what the method of the class is expecting. It's not like this stuff is new, the basics are nearly 30 years old at this point.
right, so you need a decent IDE to make it not a pain in the ass to write. nice. it's my belief that forcing the programmer to express the mundane and repetitive does NOT increase readability, or quality. conversely, if you allow the programmer to reduce the mundane, and hilight the exceptional, or unexpected you're much more likely to draw attention to those things and not have them lost in the all the noise.
I mean if you really want to go crazy you could say that none of the languages are unnecessary. Why would you ever use a pointer when you could just go to the address in assembly?
you're missing the point. i'm not saying there shouldn't be a way of calling methods (or passing messages to objects, or whatever you want to call it). I'm saying there doesn't need to be a completely new syntax invented for doing it when the existing one could have been minimally extended to support the new semantic requirements. they could have easily added smalltalk semantics to C without trying to bolt one language as an embedded DSL inside another in some frankenstein-type abomination.
sending messages, shmending messages, banana-ing function blobulators.
it's doesn't matter what you call it. it doesn't explain why there needs to be a completely different syntax for transferring control to a function that's bound to an object.
Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure
Objective-C is a superset of C, right?
so you can write to arbitrary memory locations, call arbitrary (non-NX) code locations?
unsafe.
"Modern" languages (and i'm thinking Ada, here) don't allow such things, or make it trivial to disallow them (java's JNI, c#'s 'unsafe', etc...)
does ARC handle cycles??
mono lacks complete support for the operating system libraries, but it has complete support for the language.
actually, the win32 API uses pascal calling convention. their C compiler contains a built-in bridge to pascal (__stdcall).
you have got to be kidding.
right?
ok, so they added dot-notation property access after the fact. why didn't they also add dot-notation method access while they were at it?
i'm guessing they had a really good reason for adding the property access shortcut, probably something involving everybody telling them the old way sucked (see hot pins bit, above). and yet that pearl of wisdom didn't seem to make it as far as the method access syntax. shame.
The difference can be subtle
seems artificial to me. after all, a method is just a bound function.
sure, the new semantics are useful and nice. my problem is with the syntax. there's no need to create a completely new syntax for method calls, and there's no need to require naming parameters at the call site; they should have just added optional named parameters to the existing function call syntax.
for example:
someFunction(value1, value2)
myStruct.field
myObject.method(value1, value2, optionalArg: value9);
anything else is unnecessary
Newton was wrong!
where would be to day if we'd believed him !?
I read somewhere that .NET and C# were developed by the guy that developed Delphi.
you mean Anders Hejlsberg?
but is it really that much worse than
it's not really better or worse, it's just unnecessary.
C already has a syntax for declaring and invoking functions, and it already has a syntax for accessing variables bound to instances of structs. why did they have to invent a completely new syntax for declaring and invoking functions bound to structs?
if "struct.field" is ALREADY a way or accessing a struct's field, and "function()" is ALREADY a way of invoking a function, then why can't "struct.field()" be a way of invoking a function that is a field of a struct? it's not that much of a stretch.
agreed. when i look at obj-c code it feels like someone's pushing hot pins into my eyes.
seriously.
why have (c-style) syntax for declaring and accessing variables and functions, and a completely different syntax for declaring and accessing bound methods?
it makes no sense. it doesn't add anything semantically to the language. it adds another syntax construct just for the sake of it. completely unnecessary.
and why are properties accessed using c-style syntax, and not methods?
none of the ms languages use all of the clr features. while c# and vb are getting closer over time, c++ and f# have significantly different requirements.
That's ridiculous, unless you're buying the products that are being advertised to you then you are not paying for that advertising at all.
huh?
if you buy products that are advertised, then you're paying for that advertisement.
it doesn't matter (to this discussion) who sees the ad.
thanks for that. i'll remember to use Python next time I want to write such a trivial program.
Is everything Microsoft does wrong by definition?
yes.
i think that's the definition of bigotry, right there...
or xperf?
if you want the full compiler, just download the free windows SDK.
And what do you think RAID 5 is?
inflexible?
I want one!
pfft. Werner Karl Heisenberg.