ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

First, I totally agree that the getter/syntax is confusing. This is one
thing to be changed before the 0.3 release
<http://ooc-lang.org/blog/?p=58>(because that means incompatible
changes, and incompatibles changes must
happen as fast and possible and then stay that way).

While these proposals are interesting, here are my requirements for a new
getter/setter syntax:

   1. It must be obvious which getter/setter is related to which field,
   whether you're looking at the field declaration or at the getter/setter
   definition
   2. The developer should have control over the function name (java-like
   getField() setField() should DIE). This is not too important because they're
   called automatically on assignment and on access.
   3. Auto-generated code is sneaky. The advantage with staying in a "func
   and/or something" keywords syntax is that even mildly dumb text editors
   (like Geany and friends) can recognize the existing functions

So I was thinking of something like that:

class Sumthin {

  Int secret;

  setter(secret) {
    // We obviously have one parameter of type secret. But what's its name?
  }

  getter(secret) findTheSecretName {
    // Custom-name setter: information hiding..
  }

}

Of course it's far from perfect, but what do you think ? Point 1) of my
requirements is only half filled by this suggestion, but it's the most
obvious that I can see.

Amos

2009/6/30 Vincent R. <forumer@xxxxxxxxxxxxxxx>

> Hi,
>
> When looking at property syntax I find it a bit error prone because we have
> twice the same variable name
> for variable itself and for its getter/setter method.
>
>
> // Current implementation
> class SecretKeeper {
>
> String secret;
>
> func secret
> {
> // here's our getter do stuff
> // no need to return, it's done for us automatically
> }
>
> // here's our setter: we leave it empty cause we have nothing special to do
> before setting.
> func secret(=secret);
>
> }
>
> So I am proposing some alternatives even if we agree that some proposal are
> impossible to implement. I just want to
> open the debate and force people to give news ideas and opinions :
>
>
> //Proposal 1 : inspired by .NET
> class SecretKeeper {
>
> String _secret;
>
> string Secret
> {
> get { return m_secret; }
> set { m_secret = value; }
> }
>
> }
>
>
> //Proposal 2: inspired by .NET 3.0 and automatic properties
>
> class SecretKeeper {
> string secret{ get; set; }
> }
>
>
> //Proposal 3 : AUTOGENRATED - inspired by Objective C
> class SecretKeeper {
> @property (nonatomic, retain) String secret;
> }
>
> //Proposal 4 : AUTOGENRATED _ inspired by .NET
>
> class SecretKeeper  {
> [property:readwrite]
> String secret;
>
> }
>
> Proposal 3 and 4 generated properties in the output files and property
> delcaration is implicit.
>
> Give your opinions...
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
> More help   : https://help.launchpad.net/ListHelp
>