Hi igor
I like your feedback.
Could you summarize it based on the latest alpha version and now that
you saw the code?
In the bloc version you discussed with alain (in the house I was
renovating) an element had a view that were responsibe of the rendering
but it was not good.
Stef
Le 4/4/16 20:51, Igor Stasenko a écrit :
Some more bashing today.. (don't take it personal, i may be wrong)
BlPath hierarchy.. and BlShape.
Why you redefining what is shape and what is path?
Of course, you are free to do it in Bloc..
But in terms of Athens, all of BlPath are actually - shapes..
And BlShape is some kind of encapsulation of shape, paints and transform.
It is a dumb state holder without any extra logic.
My rule of thumb: do not produce dumb state holders. They has to be smart,
else it makes no sense in creating separate entity and designating it
as something else than any other bunch of data thrown into single clump,
sitting there deaf, blind, dead and silent until someone else will
grab it somewhere
and start using it for own purpose.
Sure, i could understand, why you potentially may want such object(s)
around,
but it is not shape anymore and i wouldn't call it like that. Because
shape
are shape, and has nothing to do with paints and transform,
it don't knows and don't cares whether it will be filled or stroked or
both,
and how many times, and if there will be single paint or thousand.
Such kind of properties is simply orthogonal to what shape existing for,
because it exists only to define geometry.
I think all of that came from not understanding the roles of objects
and how they interact in Athens.
Shapes define geometry.
Paints define how that geometry will be filled/altered.
The shapes and paints are related in a way that paints are used to
fill shapes. But there's nothing tells that single shape can be
filled only once with prescribed paint, and only then stroked.. or
vise versa.
The order and amount of operations, combinations and effects are up to
the user. And they have to stay like so, if you don't intend to shrink
feature set and hardwire, what users can do and what they cannot.
I really hoping that you had no such intent.
Be on your place, if you want to have a number of commonly used
shapes, just make a
factory class, so i can tell:
CommonShapes rectangle: a@b to: c@d
except, that Rectangle is a shape already.. and wrapping it with own class
just adds more complexity, creating one extra beloved dumb state
holder and nothing else.
But i would imagine i could have:
CommonShapes circle: 100@100
or
CommonShapes roundedRectangle: 100@100 radius: 5
in any case, since there could be infinite number of 'possibly useful
objects'
when we talking about geometry.. your BlPath hierarchy will tend to
grow and grow over time, ad infinity.
Well, people love when there's order, like in that comic where guy
painted 'cat' label on his cat, 'car' label on his car.. and all
around in same way.
Can't blame for that.. So, maybe. Whatever..
But your examples demonstating insane amount of bloat..
For example:
exampleLine
self new
layoutStrategy: BlLinearLayout horizontal;
layoutParamsDo: [ :lp |
lp horizontal wrapContent.
lp vertical wrapContent ];
addChild:(self new
layoutParams: BlLinearLayoutParams new;
shape:
(BlShape new
fillPaint: (BlColorPaint new color: (Color blue alpha: 0.5));
strokePaint:
(BlStrokePaint new
paint: (BlColorPaint new color: (Color green alpha: 1));
lineStyle: BlStrokeLineStyle new;
width: 5);
path: (BlLinePath new));
extent: 400 @ 200);
openInWorld
Guys, are you serious, you will find happy users, that is forced to
produce so much
code in order to draw a single, simple line on the screen?
You must be kidding.
I see that it is indeed comes from the requirement that BlElement can
hot-swap its shape on the fly.. And so, you are forced to define all
the properties
and construct all the things in place.
But there should be some sanity limit, where you should stop asking
user for
so much details.
But if you want to go to such extreme, then all your examples would
look like that:
BlElement new
content: (MyFancyPony new);
openInWorld.
Where MyFancyPony, is a content - an object that defines shape, and
knows how to render itself and so on. A smart object, that knows how
to behave and draw itself. Not just holding state.
And number of properties and/or behavior
is then up to the user. And he is free to use anything fancy or not to
deliver content on the screen.
That would be much better. But then it will duplicate the features of
BlElement (or at least a significant subset of it) - being able to
render itself.
But still.
P.S. Now i see BlElement.. why nobody said that it is replacement for
Morph?
I was thinking that in addition to BlMorph, you have BlElement :)
Sure, you don't need two compositions. As long as there one thing that
represent UI elements, that can form hierarchy its ok.
So, i retract my comments about Elements.. And apologize.
--
Best regards,
Igor Stasenko.
