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…
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! 
yr right. I was thinking of asRect. I only had a quick glance at yr post. i should read slower next time. : )