[erlang-questions] If you are homesick for object.selector

[Richard O'Keefe]

On 25/01/2013, at 3:08 PM, Loïc Hoguin wrote:

> On 01/25/2013 01:31 AM, Richard O'Keefe wrote:
>> 
>> On 24/01/2013, at 3:37 PM, Loïc Hoguin wrote:
>>> But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person).
>> 
>> I thought the complaint was that Person#person.name is not polymorphic;
>> my point was that name(Person) _can_ be polymorphic, if you seriously
>> want it to be.
> 
> It's about ease of use, reducing the extra steps (or plane flight in the case of Erlang) to get the work done.


(1) Please let's have a real concrete example of about 1 page,
    not imaginary one-liners, with names that turn out to be
    not as intention-revealing as they look.

(2) Person#person.name is just a field selector; it can only fetch
    a stored data.  The "frames" analogue, Person~name, has the
    same basic property.  The Smalltalk analogue, person name,
    or the C# analogue, person.name, can run arbitrary code, which
    is much more powerful.

    Are we debating whether Person~name, with the same fundamental
    limitation as field access in C or Java or ML, is a really big
    improvement over Person#person_name?

    Or has the idea crept in that Person.name might run complex code?

I note that www.missioncriticalit.com claim to be able to generate
about 90% of the code in a business system (in Java, C#, or Mercury)
from semantic models.

That's _really_ where I think the big gains are going to come from.
And I expect the core Erlang ideas to be good for such systems even
if the Erlang language is replaced by a different embodiment of them.

(It should be clear, but if not:  each Domain needs its own Domain
Specific Language.  "Then Erlang needs that DSL." doesn't really
make sense.  'Then Erlang needs its own toolkit to make building
good DSLs easy' does make sense and I think it's true.

>> 	character addToInventory: item
> 
> Let me stop you right there. Nobody said anything could change Character.

And where does that line of code say anything _does_ change Character?
The _association_ between 'character' and 'item' changes, somehow.
That doesn't mean 'character' has to change.

That's the point, really.