Guess what is my choice :)
>>>>
> Yes. But i want to stress, what meaning we are putting into 'API'.
the real one :)
>
> API is protocols, not classes.
> So, a code which renders something using API, should use only messages
> sent to a canvas object.
> The difference could be illustrated by following:
>
> a)
> drawOn: aCanvas
>
> path := RomePath new.
> path moveTo: .. lineTo:... close.
> aCanvas strokePath: path
>
> b)
> drawOn: aCanvas
>
> path := aCanvas newPath.
> path moveTo: .. lineTo:... close.
> aCanvas strokePath: path
>
> In case a) you are introducing a dependency on a concrete path
> implementation(RomePath).
> in case b) you asking a canvas to provide a path instance, which
> conforms to a path protocol.
>
> Here lies the main difference, which either gives you a freedom of
> choice, or otherwise makes your code inflexible.
> That's what i mean by no dependecy.
I understood it :)
> In case b), a rendering backend is
> free to use own data structures
> to optimally reify a path(s), while in case a) you forcing a canvas to
> have an intimate knowledge about RomePath
> - a concrete implementation, which may not fit best for canvas and
> hence it will waste cycles converting a path
> representation into more appropriate form, in order to render it.
>
> That's why, if we follow path b), then morphic rendering could be
> completely autonomous,
> and do not depend on concrete Rome API implementation.
> And enforcing it from a very starting, will make sure that we won't
> introduce unnecessary
> dependencies and inflexibility.
so this is why it would be good to have a concrete scenario to stress and
validate
the Athens new canvas
I would really like to see how the one of Morphic 30 will fit into it too.
So let us start like that:
- design your API with flexibility in mind + ROME from the point of you
of Canvas method
- give feedback about athens inflexibility
- we update it
- we iterate
the goal should be that at the end we can get really fast a different back-end.
With a bit of chance we will d the same with Morphic30 and we will have a cool
system.
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
