Wasn’t sure whether to post this under questions or development…
There is a .fromRect method under Rect that takes an instance of Rect as an argument. Am I wrong or is this useless? I can understand why keeping the .asRect method makes sense with mutation.
So you could for example take a Rect, return its origin (instance of Point), do some math on it, then return another Rect. If everything is in the same line, the asRect method is helpful.
But returning a Rect given the Rect as an argument? Is this completely redundant? There are some methods in other languages that return a Rect from two other Rects (I guess it uses the difference between them or something) and others that take an instance of Rect as a particular class and change it to an instance of another class with different properties.
Should this be a pull request or am I missing something? If you know what Rect you’re looking for, just call it directly… There’s no Point.fromPoint or Array.fromArray…

1 Like

is this useless?

Not entirely!

In some contexts, for clarity, it can be nice to give a precise name to copy.

Also it can be nice to get an error at the copy site, c.f. Image.fromImage.

f = { arg aRect; aRect.copy };
g = { arg p; Rect.fromRect(p.q.r) };
f.value(nil) == nil
g.value(nil) // error

the .asRect method makes sense with mutation

But Rect>>asRect isn’t copying, it’s identity, it’s for “coercion”, as they say, c.f. asFloat &etc.

f = { arg x; x.asRect.size };
f.value(Rect(0, 0, 1, 1)) == f.value(Point(1, 1))

so you can do things like this…
[Rect(0,0,10,10), [0,0,10,10], 10, Size(10,10), Point(10,10)].collect(_.asRect)

You’re thinking of .asRect (proposing as useful), which is different from .fromRect (proposing as not useful)

I’m definitely too new to programming to have been able to make a distinction between “mutation” and “coercion”. Thanks for the correction! :slight_smile:

yr right. I was thinking of asRect. I only had a quick glance at yr post. i should read slower next time. : )