Re: [RFC] Methods and functions

[Dan Čermák]

"Jose E. Marchesi" <address@hidden> writes:

> Hi people!

[snip]

> Advantages of this approach:
>
> - It is very natural to refer to fields from methods, and also to other
>   methods, in exactly the same way than if they were variables in the
>   lexical environment.  This avoids the need to use notations like
>   `self.c' or `self.method1'.

[off-topice]
I must admit, that I actually prefer languages that don't have an
implicit this. or self. and force you to explicitly type out the self.c
or self.method. Would it be very hard to add self.XXX as an optional
thing to poke?

>

[snip]

>
> What makes me hesitate to follow this approach is that we would need to
> introduce a whole new additional set of restrictions, this time for
> regular functions defined inside struct types:
>
> - Functions cannot refer to methods as variables.
> - Functions cannot refer to struct fields as varaibles.
> - ... and so on, basically the same restrictions that exist for methods,
>   but reversed.
>
> My current opinion is that it would complicate the language, for little
> benefit: after all, it costs nothing to have prime_p defined outside of
> the struct type:

That was exactly what I was thinking: what is the point of having a
function private to a struct, if it cannot access the struct's fields?
Unless this comes with other benefits, I'd say: skip it (at least for
now).

Being able to use methods in constraints and optional field conditions
would be way cooler, but I have no idea how to implement that and that
will likely open a huge can of worms and have so many hidden traps, that
it isn't worth it.


Cheers,

Dan

signature.asc
Description: PGP signature