ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

Hi there,

I'd like to add that, it's not only a j/ooc issue, rock also has this
behavior, and for a very logical reason.

When you do:

dog := Dog new()
dog name println()

"dog name" accesses a member variable of dog, which is of class Dog
And when you do

Dog MAX_AGE

It accesses a member variable of Dog, which is a singleton instance of the
class DogClass

So in rock, I simply didn't think about unqualified static member access
(believe it or not, it
wasn't used in the hundreds of tests I ran rock on!)

In the ooc code I write, I find that it's not too much of a hassle to
qualify static member access,
e.g. write "Dog MAX_AGE", or "This MAX_AGE" instead of just "MAX_AGE",
because I seldom
use it. But some projects use many more constant and prefer to wrap them in
static member
variables (rather than at module-level) and that becomes a pain.

Qualified static member access has been enforced in j/ooc for consistency
with rock and following
a short discussion on our IRC channel #ooc-lang during which at least 2
persons expressed
their wish to make both compilers enforce that. Those who we think so should
reiterate
their arguments on the mailing list so that we can all decided on the most
reasonable solution.

Thanks in advance for your time =)

Amos Wenger (nddrylliog)

On Sat, Apr 10, 2010 at 12:08 AM, Scott Olson <scott@xxxxxxxxxxxxxxx> wrote:

> Mhh, KMail word wrapped the URL, sorry. Here it is again:
>
> http://github.com/tsion/oos/blob/covers-and-statics/Src/Kernel/Hal/Display.ooc
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>