Is there a predefined HashSet class in Haxe, similar to
s = set()
in Python or
import java.util.HashSet;
in Java?
I know, I can simply use haxe.ds.HashMap in order to quickly implement such a set, however I'm curious whether I really need to do this ...
There's no set data structure in the standard library, but that doesn't necessarily mean you have to implement one yourself. The polygonal-ds library is excellent for instance, and comes with a HashSet class (among many others).
Related
I am trying to understand how/if I can use QStringView in signal/slots that are called from QML. For example, in the below code, can I use QStringView instead of QString?
Q_PROPERTY(QString priority READ priority WRITE setPriority NOTIFY priorityChanged)
From what I am reading from the documentation, any type that is supported by QVariant can be used in a Q_PROPERTY, I can understand why QStringView is not supported by QVariant but I am looking for a way to use QStringView with QML, instead of passing QString copies between the two all the time.
The supported conversions between QML and C++ data types are described in this document.
The supported data types could be split into four categories:
Basic datatypes
QObject derived classes (ex. QAbstractItemModel)
Some basic lists
Enumerations
Answer:QStringView is not part of any of these categories. So, it is not possible to transfer it to QML.
Possible workaround: You could try to create a QObject based wrapper around QStringView, which implements the desired QML interface.
I want to use the Union and Optional types when creating a dataclass.
Can I use these types safely?
E.g.:
#dataclass
class Car:
year: int
owner: Optional[str]
engine: Union[Engine1, Engine2]
Yes you can. First off, annotations in python don't do anything by themselves. From other languages you might expect that declaring a variable as int will lead to an error if it is instantiated as, say, a string, but that just isn't the case in python.
Annotations are only used by third party libraries or tools, like your IDE when it gives you hints, or mypy when it does a static type analysis of your code.
So you should use a kind of annotation that your tools work well with, and from my personal experience that would mean to use the type annotations from the typing module over the basic types.
While there is no declarative statement on what you must use, here is a thread discussing default dataclass types including ericvsmith (the author of the dataclasses module) and gvanrossum (the author of python), and they agree that typing.Any should be preferred over object.
I assume the dataclass documentation uses basic python types in order to not place too much of a burden of knowledge on the reader. You can use dataclasses just fine without knowing anything about the typing module after all, and once you are comfortable with how dataclasses work, you're probably going to run into and appreciate the additional power of using typing's annotations anyway.
I am a self-taught python user (kind of.). I read much to deepen my knowledge about python. Today
I encountered a text saying:
... classes and objects ....
So I was wondering what is the difference between objects and classes in python. I taught all classes are objects, but in that case, author wouldn't have used phrase "classes and objects". I'm confused...
These are two closely related terms in object oriented programming. The standard meaning is that an object is an instance of a class.
An object is an instantiation of a class.
Think of a class like the blueprint of a car.
Ford make cars (objects) based on the rules and information enclosed in the blueprint.
Yes, classes (and functions, and modules, and basically everything) in Python are objects, too. The difference lies in their types:
class Foo(object): pass
print type(Foo)
print type(Foo())
To see they're both objects, you can check that they both have attributes:
print dir(Foo)
print dir(Foo())
A class describes what that object will be, but it isn't the object itself.
A class is an idea. An object is the fruition of that idea.
I have a couple of stateless classes that do some business logic and return some computations. Each one of them has naturally a set of dependencies on other classes.
Now there are two designs that I've juggling between:
Have a class where each method is a static method. I can use jest import mocking, to overwrite the dependencies for testing. Advantage is you only have one class instance.
Have a class with regular non-static methods. This would require instantiating the class in each place it is used. I can pass in class dependencies in the constructor. Testing this is pretty straightforward. Drawback is you create multiple class instances and potentially dependencies in the code.
Which of these is the preferred idiomatic TS approach?
There is also the classic solution of using an IoC container, but I'd like to avoid this since this application is fairly small and don't want to add extra bloat.
Also, don't want to export pure functions and forego classes all together since that means I'll lose auto-importing of classes (in VSCode).
Also, don't want to export pure functions and forego classes all together since that means I'll lose auto-importing of classes (in VSCode).
Can you explain what is this "auto-importing of classes (in VSCode)"? In VSCode, I'm using extensions like TypeScript Importer that adds the appropriate imports for any type (class, function, literal...), not only for classes.
Anyway, IMO, it's the "pure functions" approach that is the more JavaScript idiomatic, at least for those (including me) who likes the JavaScript functional programming features. It's true for TypeScript too, even with its sympathy for classes and C#/Java-like object oriented programming.
If you really prefer classes, avoid static i.e. option #1. You can instanciate and share instances while bootstrapping your application (like a DI container would do) to avoid multi instances.
Coupling between classes is less an issue in TypeScript due to its structural typings: a class can act as an interface → if class A depends on class B, you can always provide a class B-like object to the class A instance.
Vtables are ubiquitous in most OO implementations, but do they have alternatives? The wiki page for vtables has a short blurb, but not really to much info (and stubbed links).
Do you know of some language implementation which does not use vtables?
Are there are free online pages which discuss the alternatives?
Yes, there are many alternatives!
Vtables are only possible when two conditions hold.
All method calls can be determined statically. If you can call functions by string name, or if you have no type information about what objects you are calling methods on, you can't use vtables because you can't map each method to the index in some table. Similarly, if you can add functions to a class at runtime, you can't assign all methods an index in the vtable statically.
Inheritance can be determined statically. If you use prototypal inheritance, or another inheritance scheme where you can't tell statically what the inheritance structure looks like, you can't precompute the index of each method in the table or what particular class's method goes in a slot.
Commonly, inheritance is implemented by having a string-based table mapping names of functions to their implementations, along with pointers allowing each class to look up its base class. Method dispatch is then implemented by walking this structure looking for the lowest class at or above the class of the receiver object that implements the method. To speed up execution, techniques like inline caching are often used, where call sites store a guess of which method should be invoked based on the type of the object to avoid spending time traversing this whole structure. The Self programming language used this idea, which was then incorporates into the HotSpot JVM to handle interfaces (standard inheritance still uses vtables).
Another option is to use tracing, where the compiler emits code that guesses what the type of the object is and then hardcodes the method to call into the trace. Mozilla Firefox uses this in its JavaScript interpreter, since there isn't a way to build vtables for every object.
I just finished teaching a compilers course and one of my lectures was on implementations of objects in various programming languages and the associated tradeoffs. If you'd like, you can check out the slides here.
Hope this helps!