This references says printable<%> should be implemented, and that it seems to be a wrapper around prop:custom-write.
https://docs.racket-lang.org/reference/objectprinting.html
But the docs for prop:custom-write say it's deprecated in favor of gen:custom-write.
If you are using the Racket class and object system, then implement printable<%>.
If you are using structs, then use gen:custom-write.
Related
Disclaimer: I'm still learning Swift so forgive me if I haven't understood certain concepts/capabilities/limitations of Swift.
With the Swinject framework, if you wanted to bind a protocol to a class - it seems you have to return the class instance in a closure such as:
container.register(Animal.self) { _ in Cat() }
Is is possible to be able to instead pass in two types to the register() method and have the framework instantiate the class for you? It would need to recursively see if that class had any initializer dependencies of course (Inversion of Control).
This is possible in the PHP world as you have the concept of reflection, which allows you to get the class types of the dependencies, allowing you instantiate them on the fly. I wonder if Swift has this capability?
It would be much nicer to write this:
container.register(Animal.self, Cat.self)
This would also allow you to resolve any class from the container and have it's dependencies resolved also (without manually registering the class):
container.resolve(NotRegisteredClass.self)
Note: This only makes sense for classes that do not take scalar types as a dependency (as they need to be explicitly given of course).
The second case - resolving a type without the explicit registration - is currently not possible because of Swift's very limited support for the reflection.
However, there is a SwinjectAutoregistration extension which will enable you to write something very close to your first example:
container.autoregister(Animal.self, initializer: Cat.init)
I'm searching quite a while now but I cannot find anything. Is there a possibility in Swift to supply an own implementation of a class or a method without touching the library. Subclassing would not be an option.
As Example from ios charts (https://github.com/danielgindi/ios-charts) I only want to replace the LineScatterCandleRadarChartRenderer class (https://github.com/danielgindi/ios-charts/blob/master/Charts/Classes/Renderers/LineScatterCandleRadarChartRenderer.swift) or the single method it is implementing. It is a subclass of a subclass of a subclass used somewhere in the library when plotting the chart.
What would be the best practice to do this?
I found an answer for python: Cast base class to derived class python (or more pythonic way of extending classes)
I've been trying to find the best way to implement a stored property in an extension, and came across this question: Swift extension stored properties alternative. However, I have not found a reason why in the discussion or anywhere else. Is there a reason why stored properties are not allowed in Swift? And if so, what is the reason?
Extensions are for extending the functionality of an existing class without changing the memory structure. It's more or less syntactic sugar. Imagine you could add stored properties and methods, what would it be? Nothing else but inheritance. So if you like to add new properties and methods just inherit from the class.
Just to be sure, has Dart removed explicitly defining an interface now in favor of implicitly defining it via abstract?
I see it mentioned in Dart and Interface Segregation Principle, however I'm also finding a lot of content still referencing the explicit definition, such as When to use interfaces in Dart?
Yes. The interface keyword was removed from Dart. Instead all classes have implicit interfaces. So if you want to define an interface you can use an abstract class instead.
See this blog post from 2012 about eliminating the interface keyword.
What is the correct way to create an instance from another Moose object? In practice I've seen this done numerous ways:
$obj->meta->name->new()
$obj->new() ## which has been deprecated and undeprecated
(blessed $obj)->new()
-- and, its bastard variant: (ref $obj)->new()
$obj->meta->new_object()
And, then what if you have traits? Is there a transparent way to support that? Do any of these work with anonymous classes?
Of your choices, $obj->meta->name->new() or (blessed $obj)->new() are both the safest.
The way traits are implemented, you create an anonymous subclass and apply the roles to that subclass and rebless the instance into that subclass. This means that either of these solutions will work fine with traits. Perl lacks truly anonymous subclasses (every package has to have namespace), Moose works around this by creating a name in a generic namespace for anonymous classes.
If you'd taken a second to try some example code, you'd see this in action.
$perl -Moose -E'with q[MooseX::Traits];
package Role; use Moose::Role;
package main; say Class->with_traits(q[Role])->new->meta->name'
MooseX::Traits::__ANON__::SERIAL::1
Hope that helps.