Re: “Verb tuples” for properties, fac eting, and namespacing methods

On 2012 Nov 3, at 15:53 , Kevin Reid wrote:

> Properties can be seen as in opposition to object-oriented programming, because they encourage the view of an object as state without behavior, as being not an active participant in the system. However, object-orientedness is not all there is to be had, and here are some use cases for properties which I see as relevant:

Consider the standard Scheme code:
(define cc (lambda () (let ((c 0)) (cons
    (lambda () (set! c (+ c 1))) ; incrementer
    (lambda () c))))) ; getter
It returns a pair of functions which I presume you would call 'properties'.
One difference is that the neither party need name the properties.
That difference is sometimes good and sometimes bad.
(I dislike language constructs that force you to name something before you can use it. A minor annoyance.)
The caller of cc can disseminate them to others as a pair or individually.
This latter is an advantage over most OO systems where you can only attenuate the 'object' by defining new objects.

Said another way does "foo.bar(13)" mean "(foo.bar)(13)"?
If so then the language is easier to understand and you have this possibility of direct dissemination.
You can use "foo.bar" as an argument; it is a mere function.

All this raises the issue of sibling communication.
In C++ and several other OO languages the text "A.b" within the definition of class X accesses field b of a sibling object A if A is known at compile time to be an object of class X.

This is useful, in fact vital to a class of applications.
It is efficient synergy. I do not recommend it here.
I have not understood the E synergy story.
It is not addressed in Scheme.
A primitive sealer-unsealer would do nicely and be a bit less efficient, and more conservative authority wise.
I describe my favorite Scheme solution here: http://cap-lore.com/Languages/Scheme/Syn.html
It lays out the apparatus on the table more clearly than the traditional OO schemes, in my opinion.

Properties annihilate the V-table where the code pointers are kept next to the object state.
Each 'property' must point to the shared state and code, just like a fat-pointer.
It is, as we said, a mere function.
This is an efficiency that will missed by a few.

Have I badly misunderstood your meaning of "property"?