ooc-dev team mailing list archive

[Alec Benzer <alecbenzer@xxxxxxxxx>]

Well, I'm not entirely sure what solution would be best suited for your
vision of the language, but I would have an idea for what I personally would
prefer.

Note that my knowledge of ooc at this time is imperfect so some of what I'm
saying might be incorrect.

First, I would make the conceptual assumption that ALL variable access is
done via properties. Ie, there is no such thing as a plain instance variable
vs a property. This wouldn't really have any implications as far as
implementation of ooc goes, but I think it would make solutions to this
problem more philosophically consistent. And it seems to make sense.
Consider the expression obj x. We have no guarantees about what this does.
This could be returning a simple instance variable, or it could start a
computation that takes 10 seconds to finish. More specifically, we have no
way of knowing whether or not this is a property, so it would seem to make
sense to "assume the worst", that it is a property and might be doing
complicated stuff. The fact that it might be a simple variable that makes no
calls can be considered a sort of "optimization" on the compiler's part
should that be the case.

Once we assume that all variable access is done through properties, it
follows pretty obviously that all instance data is, essentially, private
(otherwise there would be a way to access instance data other than through a
property).

Now, we come to the part that actually makes a difference, how to
distinguish between direct instance data access (within a class) and
property access. A solution that might be unobtrusive to current syntax is
to have something like "this member_name" use properties for access, while
"member_name" by itself would offer direct access. This makes some sense in
that all expressions of the form "obj member" would be using properties, so
it makes sense that "this member" would have to too, but there are issues
here, namely, it prevents you from being able to distinguish between a
parameter called "member_name" and the actual member (though I'd assume this
comes up most often in constructors, which isn't an issue for ooc because of
the init(=member) syntax). There's also the issue of people assuming "this
x" and "x", when there is no name conflict, are equivalent statements, which
would no longer be the case.

A better solution might be to follow ruby's model, ie, use something like
@member to refer to instance data directly. @ is taken in ooc, but perhaps
something like $member? (unless that's taken too).

Again, this is all based on my personal taste. You guys might
have qualms with this kind of an approach, and prefer to stick with the
current implementation of things.

Also, I think this way of doing things would be a bit more powerful than
solving this simple issue. For example, say you have a class with a public
instance field foo that you let users mutate freely. But then, during an
update to the class (which is already being used elsewhere), you decide that
allowing users to mutate foo directly would be problematic, so you try and
make it a property, but do not create a setter. In a model that allows
direct instance data access, this could work fine. but currently (unless I'm
misunderstanding something), it is effectively pointless to have a
(non-virtual) property with no setter, since absolutely nothing would be
able to set the data to anything. (of course, you could solve this by
creating an instance variable named _foo, change foo into a virtual
property, and then change all references within your class of foo to _foo,
though again, this feels a bit sloppy, though it's still a much better
solution than if you mistakenly had public instance data in something like
C++ or Java).

My two cents.

On Sun, Sep 26, 2010 at 5:22 PM, Friedrich Weber <
fred.reichbier@xxxxxxxxxxxxxx> wrote:

> Sure it is possible to add syntax to do that. However, we should be
> sensitive about adding syntax, especially if we add them for special use
> cases. But I see your point, though I personally think the Pythonesque
> approach isn't that ugly. Can you come up with a consistent and nice idea?
> :)
>
> Cheers
>