I've just started playing with Unicon classes and thought
people might have fun poking holes at the following...

I'm not particularly fond of the fact that there are no
private members in Unicon classes [yes, I understand the
arguments as to why others like having only public members
and won't rehash my reasons for prefering them].

So I was just thinking about how to get closer to providing
some sort of protection for some members (variables in this
case) and came up with the following idiom that gets closer
[access is still available through an access method, but I
can live with that for now].

Best shown with an example, suppose I have a class with two 'public'
variables 'a' and 'b' and I want to have a 'private' variable 'c':

    class foo(a,b)

        method accessC(newC)
            static c
            c := \newC
            return c
        end

        # other methods get to 'c' using accessC()...
        ...

    end

In fact the above access method is an interesting idiom in itself -
a single method that acts as both a 'getter' and and 'setter' (it's
a getter if called with no [or null] argument, otherwise it's a
getter [ok, it's *always* a getter]).

So I could provide access to 'a' [and 'b'] using the same approach:

        method accessA(newA)
            a := \newA
            return a
        end

and help keep those people who believe all member variable access
should be through getter and setter methods happy.


-- 
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
                    monax materiam possit materiari?


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group

Reply via email to