I have been wondering about a stupid thing about the DOM. Why do the standards define NodeList with the postfix List to make it clear it is an array while have a some properties or functions like childNodes or getElementsByTagName which use the postfix letter s?
I find it contradictory when the standards define members with different suffixes for the same purpose (to describe an array).
Edit: It actually seems that NodeList is not even an array. Does this explain this?
NodeList is an interface.
childNodes is a member of the Node interface.
getElementsByTagName is a member of the Document interface.
BTW, both these members return a value of type NodeList.
So, there is a difference: one is an interface, and the other two are members of interfaces.
Related
Can this be written as a single line?
assertThat(actualDeltas)
.filteredOn(delta -> delta instanceof Replacement)
.asInstanceOf(InstanceOfAssertFactories.list(Replacement.class))
I expected asInstanceOf to do the filtering. Alternatively, I searched for extractors or other concepts, but couldn't find any simple solution.
Is that possible with assertj?
By design, the purpose of asInstanceOf is only to provide type-narrowed assertions for cases where the type of the object under assertion is not visible at compile time.
When you provide InstanceOfAssertFactories.list(Replacement.class) as a parameter for asInstanceOf, you are telling AssertJ that you expect the object under assertion to be a List with elements of type Replacement.
While asInstanceOf will make sure that the object under test is a List, it will neither filter nor enforce that all the list elements are of type Replacement. The Replacement will ensure type-safety with subsequent methods that can be chained, for example with extracting(Function).
Currently, filteredOn(Predicate) or any other filteredOn variant is the right way to take out elements that should not be part of the assertion. If the filtering would happen outside (e.g., via Stream API), no asInstanceOf call would be needed as assertThat() could detect the proper element type based on the input declaration.
In js_of_ocaml, is it possible to get the child nodes of Dom_html.element?
I know that the class inherits Dom.node, and thus has the childNodes method. But since it is a method from Dom.node, it returns values of Dom.node types. And I need those nodes to still be Dom_html.element, or else most methods will not be available.
Since downcasting is not possible in OCaml, I do not find any possible solution for this issue. Am I missing something or is this really impossible?
childNodes cant't be typed as a collection of Dom_html.elements because the nodes returned can, and are likely to, include nodes that are not elements, such as text nodes.
The DOM standard defines a property children on Element which would only return the elements, but that still wouldn't get you to Dom_html.element. And unfortunately it also does not seem to be included in JSOO's Dom.element.
You can use the element function of Dom.CoerceTo to safely coerce Dom.nodes to Dom.elements, but I don't think there is any generally reliable way to go from Dom.element to Dom_html.element, because the DOM is unfortunately too dynamically typed.
You might have to check the tagName manually and (unsafely) cast it using Js.Unsafe.coerce.
I'm new to scala(just start learning it), but have figured out smth strange for me: there are classes Array and List, they both have such methods/functions as foreach, forall, map etc. But any of these methods aren't inherited from some special class(trait). From java perspective if Array and List provide some contract, that contract have to be declared in interface and partially implemented in abstract classes. Why do in scala each type(Array and List) declares own set of methods? Why do not they have some common type?
But any of these methods aren't inherited from some special class(trait)
That simply not true.
If you open scaladoc and lookup say .map method of Array and List and then click on it you'll see where it is defined:
For list:
For array:
See also info about Traversable and Iterable both of which define most of the contracts in scala collections (but some collections may re-implement methods defined in Traversable/Iterable, e.g. for efficiency).
You may also want to look at relations between collections (scroll to the two diagrams) in general.
I'll extend om-nom-nom answer here.
Scala doesn't have an Array -- that's Java Array, and Java Array doesn't implement any interface. In fact, it isn't even a proper class, if I'm not mistaken, and it certainly is implemented through special mechanisms at the bytecode level.
On Scala, however, everything is a class -- an Int (Java's int) is a class, and so is Array. But in these cases, where the actual class comes from Java, Scala is limited by the type hierarchy provided by Java.
Now, going back to foreach, map, etc, they are not methods present in Java. However, Scala allows one to add implicit conversions from one class to another, and, through that mechanism, add methods. When you call arr.foreach(println), what is really done is Predef.refArrayOps(arr).foreach(println), which means foreach belongs to the ArrayOps class -- as you can see in the scaladoc documentation.
Scala has both a mutable and an immutable Map ,
but it has only an immutable List.
If you want a mutable List you need a ListBuffer.
I don't understand why this is so.
Any one knows?.
You can choose between these:
scala.collection.mutable.DoubleLinkedList
scala.collection.mutable.LinkedList
scala.collection.mutable.ListBuffer
scala.collection.mutable.MutableList
So, yes, Scala has mutable lists :-)
I hope that this article may be of some use to you. The diagram at the bottom of the page is particularly useful in providing the mutable and immutable classes.
http://www.scala-lang.org/docu/files/collections-api/collections_1.html
There is a mutable List, but it is called Buffer. The article linked by Graham goes into more depth, but I thought there should be a specific answer to the question as well.
Map is a trait -- like Java's interface --, while List is a class, a concrete implementation of a Seq. There are mutable and immutable Seq, just like for Map.
This may be confusing to Java programmers because, in Java, List is an interface, whose (main) implementations are ArrayList and LinkedList. Alas, Java naming is atrocious. First, ArrayList is not a List by any stretch of imagination. Also, the interface has methods that are not really related to any traditional list.
So, if you want mutable/immutable equivalence, look to concrete subclass implementations of Seq.
I have a collection of objects and for each object I have its type FullName and either its value (as string) or a subtree of inner objects details (again type FullName and value or a subtree).
For each root object I need to create a piece of XML that will be xml de-serializable.
The problem with XmlSerializer is that i.e. following object
int age = 33;
will be serialized to
<int>33</int>
At first this seems to be perfectly ok, however when working with reflection you will be using System.Int32 as type name and int is an alias and this
<System.Int32>33</System.Int32>
will not deserialize.
Now additional complexity comes from the fact that I need to handle any possible data type.
So solutions that utilize System.Activator.CreateInstance(..) and casting won't work unless I go down the path of code gen & compilation as a way of achieving this (which I would rather avoid)
Notes:
A quick research with .NET Reflector revealed that XmlSerializer uses internal class TypeScope, look at its static constructor to see that it initializes an inner HashTable with mappings.
So the question is what is the best (and I mean elegant and solid) way to workaround this sad fact?
I don't exactly see, where your problem originally stems from. XmlSerializer will use the same syntax/mapping for serializing as for deserializing, so there is no conflict when using it for both serializing and deserializing.
Probably the used type-tags are some xml-standard thing, but not sure about that.
I guess the problem is more your usage of reflection. Do you instantiate your
imported/deserialized objects by calling Activator.CreateInstance ?
I would recommend the following instead, if you have some type Foo to be created from the xml in xmlReader:
Foo DeserializedObject = (Foo)Serializer(typeof(Foo)).Deserialize(xmlReader);
Alternatively, if you don't want to switch to the XmlSerializer completely, you could do some preprocessing of your input. The standard way would then be to create some XSLT, in which you transform all those type-elements to their aliases or vice versa. then before processing the XML, you apply your transformation using System.Xml.Xsl.XslCompiledTransform and use your (or the reflector's) mappings for each type.
Why don't you serialize all the field's type as an attribute?
Instead of
<age>
<int>33</int>
</age>
you could do
<age type="System.Int32">
33
</age>