Re: [handly-dev] Choice of interface detail and parameter types

[Vlad Dumitrescu <vladdu55@xxxxxxxxx>]

Hi!

On Mon, Sep 29, 2014 at 4:45 PM, Vladimir Piskarev <pisv@xxxxx> wrote:

Regarding IParent and IOpenable, I just didn't feel they were necessary.
Do they add anything substantial? TBH, I don't think so; they rather look
like legacy code to me.

I think the place where the difference would be most visible is when traversing the model. One has to use "x instanceof IParent" vs "x.getChildren()!=Body.NO_CHILDREN" (or "x.getChildren().length!=0"), and "x instanceof IOpenable" vs "x.peekAtBody()!=null" to know what kind of element x is. I feel the intent is more clear, but it's not a big deal given how the rest of the APIs are built. You are "hiding" this functionality in the Body class, so it's not visible to the world.

In general, Handly is not merely a (partial) copy of the Java Model design.
I was interested in generalizing/streamlining/clarifying intent/and yes...
some redesigning. Unfortunately it may complicate fitting existing models...

Sometimes it is necessary to rethink things, especially those that are old and burdened by having to be backwards compatible.

 

With regard to arrays vs. collections... It's a good question. I preferred to stay
with arrays mainly because existing Eclipse Platform APIs heavily used them.

They rather look like legacy code to me ;-)

 

Somehow, arrays feel more 'robust' to me for such APIs -- simple, compact,
common denominator. I understand many would disagree...

Well, my issues with arrays are that:

- when returned from a method without using defensive copying they are exposing the internals of the object (hence the javadocs saying "Clients <b>must not</b> modify the returned array"). 

- there is a lot of copying if one wants to make sure that the client can't inadvertently modify the content. 

- using arrays together with generics can be tricky

- operations (add, remove, etc) need to be handcoded

- one can't use the collections sort/filter/etc operations (without converting to a list/set first)

I am using Xtend quite a lot and there arrays are autoconverted to lists if needed, but just like autoboxing this can be a hidden source of bad performance.

 

I'm afraid they are just that -- design choices. We can discuss them, of course.
But since they affect the whole code base and existing clients, it would be quite
difficult to change them, so I must clearly understand the benefits of doing it.

Of course! On the other hand, it would be easier to change things now than later. That's why the major version number is zero :-)

/Vlad

 

 

_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev