[prev in list] [next in list] [prev in thread] [next in thread]
List: e-lang
Subject: Re: [e-lang] Joe-E
From: "Rob Meijer" <capibara () xs4all ! nl>
Date: 2010-04-30 19:04:05
Message-ID: 0888b8462e5e659b99fa72feb5e089a5.squirrel () webmail ! xs4all ! nl
[Download RAW message or body]
On Fri, April 30, 2010 18:41, David Wagner wrote:
> Rob Meijer wrote:
>> wouldn't it be more logical for any 'container' templates to be made
>> honorarily transitively Powerless with respect to T ? That is, a
>> smarter
>> validation rather than a richer library ?
>
> Can you explain more what you are proposing? I don't follow yet...
>
> In Joe-E, collection classes like ImmutableArray and PowerlessArray are
> provided by the Joe-E library. They are exempt from static verification,
> and instead are carefully manually vetted.
>
> We can't ever allow creation of an ImmutableArray that contains a
> non-Immutable elements, because other code relies upon the property
> that every object of type ImmutableArray<T> is guaranteed to be
> Immutable, regardless of the type T. (Reminder: Immutable is a
> transitive property.)
>
> We generally can't reuse Java collection classes, because they generally
> aren't capability-safe and don't have the properties we need.
Ok, that basically disqualifies most of what I tried to suggest.
What I suggested was that if you have 3 classes:
* String ( Powerless)
* PowerfullFoo ( non powerless )
* PowerlessBar ( Explicitly Powerless)
Than for any collection class for example the priority queue you could
transitively infer:
* PriorityQueue<String> ( Powerless )
* PriorityQueue<PowerfullFoo> ( non powerless )
* PriorityQueue<PowerlessBar> ( Powerless )
But if as you stated those containers like PriorityQueue aren't capability
safe, such inference would not be possible.
But given this major issue, and given the fact that a
CapabilitySafePriorityQueue would be needed anyway if anyone needed a
priority queue, would it not still make more sense to look at the explicit
tagging for generics, for example introducing a 'CapabilitySafeContainer'
concept, for what these simple inference rules would make sense? That
would seem like a lot less work than having to rewrite capability safe
alternatives for all of the java ones?
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic