On Tue, Nov 5, 2013 at 6:19 AM, Jonathan S. Shapiro <[email protected]> wrote:
> [Please note new subject line becasue of the POLA discussion]
>
> On Tue, Nov 5, 2013 at 2:01 AM, Matt Rice <[email protected]> wrote:
>>
>> FWIW, I had at least once considered interior pointers to structures
>> nested in the object as potentially more POLA friendly than passing a
>> this pointer as an alternative to distinct object types which might
>> have a mincing effect.
>> that style would certainly seem to increase interior pointer numbers...
>
>
> Can you explain how interior pointers help provide POLA? It's hard for me to
> imagine how they are useful for this in the absence of an (unsafe) function
> that lets you recover the exterior object reference for use in the functions
> that implement your object.

Through something like Traits where the methods are declared as
accepting some set of fields rather than a specific object type.  Thus
you can pass in an interior pointer inside an object that implements
that field set to a method which requires it.

> Also, what POLA constraint were you trying to achieve?

In general was just trying to achieve object.verb without having to
pass excess fields not required to complete the objects task.  While
at the same time attempting to avoid passing in each field explicitly
as an argument.

> It might be worth trying to understand what was missing in the language that 
> pushed you to
> "perverse" solutions. -)

In general its just a feeling that inheritance is conflating many
different things,
not least of which is the public/private dichotomy by naming field
sets/traits and abstraction I was trying to avoid lumping things into
the category of public/private
as neither can always be adequately described as a single scope.

and in general avoiding the dreaded diamond problem where
fields/methods: {h,j,k} depend on field/method {a}, and {x,y,z} depend
on {a}, thus {a,h,j,k,x,y,z}
this leads to the situation that its a heck of a lot easier to put
something together than it is to take it back apart.  So without
something like interior pointers, I tend to get objects at an
annoyingly fine granularity lest I get stung by an angry platypus.

the pedantic dependency graph management through composition is the
price paid for trying to maintain very small subsets of a large system
in parallel, which leads to somewhat conflicting ideals of keeping the
small subset small, and the complete set still comprehensible.  Most
languages never even consider scaling down which can be testified by
the size of most standard libraries...

anyhow I just meant to say that style would seem to possibly dictate
number of interior pointers.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to