Remove Object.as* method to make refactoring easier #6065
Replies: 2 comments
-
One thing that occurs to me is that many languages just shift this responsibility to the target class. Rather than Object.asString you require String(fromObject: Object) - which I like because it explicitly types and can throw an error if the transformation can't be done. It moves the responsibility to the Target (which knows about its implementation more specifically) and out of a base class. |
Beta Was this translation helpful? Give feedback.
-
There are three cases we should distinguish here:
The current issue is about the third, I suppose? I don't really see hat makes it desirable to change anything about the first, but in case this is what is planned, it would be good to describe what we gain from it, and weigh it against the work it causes. |
Beta Was this translation helpful? Give feedback.
-
Yesterday at the first class library dev. metting, the need to refactor and split apart the library into more manageable chucks was deemed necessary. (I'd tag everyone present but I don't know all your github names, only scsynth names!) @joshpar
One issue we might/will run into is the
.as*
methods, e.g.,asString
,asArray
.asStream
, in the core Object class and elsewhere in the library.Generally, extending any of the base classes to do a conversion should be heavily discouraged, but we don't have a good way to do this - or at least a standard way.
Here is my proposition...
as*
methods in Object.this.as(ClassName)
syntax to do a lookup for the methodClassName.newFrom$this.classOrSuperClass
.As the method in point 2 looks the conversions up in order of inheritance this works on all object.
This way the newly added class stays in the quark/library file and doesn't need to be added to any core files.
One alternative might be to use the class extension methods to add an
asFooBar
to Object, but this is going to make it very difficult to manage as the key root object will have its parts strewn across many different files - this has probably already happened a bit. Extending class methods rather than instance is also safer as it doesn't force an interface on an object, but acts more like a free function. ThenewFromXX
is also quite hard to use incorrectly and if classes already have this method it should just work with it.There is also the downside that this is much slower, but, shouldn't conversions like this be discouraged anyway? One example is the
asArray
method, since supercollider is a rank polymorphic language it would surely be better to check therank
and switch on that.I also raised an issue #6064 that would allow for passing named arguments through
doesNotUnderstand
making this even nicer.This is quite a big change, I'm not suggesting it be adopted, but it quickly decouples many parts of the code and offers a standard way for quark/library authors to get conversions that creates less coupling, making this easier to refactor in the future.
Beta Was this translation helpful? Give feedback.
All reactions