Re: [RFC] Methods and functions

[Jose E. Marchesi]

Hi Dan.

    > 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?

Not very hard, but I think it would be confusing to provide two
different ways to do the same thing, without a very good reason to do
so.
    
    > 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.
    
The problem is that at the time the constraints and the optional field
conditions are evaluated, there is no struct value yet: it is actually
being constructed/mapped...