measure()

[trych]

After I have been using the new transform() function for a while now, I came to the conclusion that it feels quite awkward to use it for measuring something. Example:

transform(myPageItem, "rotation");

Although we decided initially to create transform as a setter and getter, the term does not really work for a getter. If I am just using it to get the rotation of an item, I am not transforming anything, hence the term feels wrong. My suggestions therefore is to introduce a function named measure() that allows me to do exactly that: measure transform properties of an object.

It could simply be a wrapper of transform() that allows getting values, but I think, if we have this measure() function anyways, we could make it even more useful. I think it could

• replace bounds() and therefore also measure typographic features (in case my item is text).

• unlike bounds() it could measure specific properties only. Example:

  measure(myWord, "baseline");

  could measure the baseline of each word only and would therefor be much faster than bounds() measuring and calculating all the properties.

• it could be used to measure page and spread bounds as well

I think the syntax measure(myItem, "property"); is a bit easier and more basil-like than bounds(myWord).property. Since we can make breaking changes before 2.0, now would be the best time to make a change like this.

@basiljs What do you guys think?

[ffd8]

I think it's an issue of semantics for 'transform', which does imply that one is actually changing something. It's normal with the typo() function among others to use it as getter/setter.. Additionally property() isn't working as a getter, which it could/should? Maybe transform() is still the wrong word for what it's doing? Should it be merged with and extending property()? (haha which I'd also shorten to just prop() to match typo()).

Nevertheless bounds() is really useful, since I'm/we're typically using the 4-5 properties returned (left, top, width, height, baseline):

var bnds = bounds(obj);
rect(bnds.left, bnds.top, bnds.width, bnds.height);

which has been fine for students... but true, there aren't so many getters that return an object.

[trych]

Yes, exactly, it is a semantic issue. That's why I would like to add measure() so skip the awkward transform(item, "property") for measuring.

The bounds thing could simply be solved by offering the possibility to do measure(item, "bounds") and then this could give us the object that we know from bounds. I thinkt it would be nicer to have all this in one function called measure().

Also, the bounds() function is quite broken, so we would need to fix this anyways, so we might just implement it in measure() instead.

[trych]

@fabianmoronzirfas @b-g
Would also like to hear the opinion of the others on this before we take any further action.

[ff6347]

measure can return values transform can return values typo can return values… You guys are working with newcomers currently. IMO it is a bit too many ways to have a getter and I wouldn't know which one is the "right one". Having a less generic getter like transform for a specific type of values feels better. I would vote for repairing the property function (is property recursive?)

• Can measure also be used as setter?
• Will the other getters be deprecated?
• I like the idea that typo returns typos … 🤣?

[trych]

I would vote for keeping things clean and therefore having

• transform() as setter only
• measure() as getter only
• discontinue bounds() entirely, include its functionality in measure() instead

This way we have transform() to transform things and measure() to measure things. That's imho the cleanest and also most simple to understand for newcomers.

[b-g]

Hi all! Many thanks @trych for the ping!

Just read through the entire issue with "fresh eyes" ... I agree that using transform as a getter reads/feels odd. When I wrote initially the bounds function I simply was not thinking it through and never anticipate that there could be used a need for measure more than the typical bounding box things ... but measure would have been the better name for it.

Basically I fully agree with:

• transform() as setter only
• measure() as getter only
• discontinue bounds() entirely, include its functionality in measure() instead

[trych]

@ffd8 Would that be okay for you as well?

[ffd8]

Awww.. I still dig the bounds() function, but as @b-g created it.. he can bless it's removal. It's compact and has worked great thus far.. suure minor snags in special canvasMode()s...

I also don't quite get the reasoning to tweak some functions to only be getters and others setters.. nice that most of the functions set if 2+ value[s] is given, otherwise acts as getter. Not too hard to teach to beginners. More unique words = more vocab for them to learn. Nevertheless, I'm open to the change and curious, what would the proposed replacing of bounds() look like? Would it still be possible to grab the bounds with a single line of code? (above was example for just the baseline). Hoping one wouldn't need to write 4x lines of measure() for the L, T, W, H of an object.. or know to type in the specific property "geometricBounds"?

[trych]

I'm open to the change and curious, what would the proposed replacing of bounds() look like?

I think it would just work like this:

measure(myPageItem, "bounds");

And there you get back your bounds object as you were used to, which should make for an easy transition for those bounds lovers. 😉
Also, there is nothing really wrong with bounds (apart from its bugs), but as it is of limited use compared to a proper measure() function (cannot return rotation, scale etc.), I think it makes most sense to implement it in the measure() function itself.

Will assign myself to this then, if that's okay.

[b-g]

Great! :)

What about having measure(myPageItem); return a similar object (maybe with even more props) like the current bounds(myPageItem);?

[trych]

Yes, that's a good idea. It will be a slower than doing measure(myPageItem, "property"), but sometimes if you don't care about speed then it's nice to have this for the simplicity of the syntax.