For example,
I have hashSet like this
Protected ReadOnly Property idsOfExistingOrder As HashSet(Of String)
It's ReadOnly
However, the ReadOnliness of that variable simple means that outsider cannot change the HashSet. It can still say add element to idsOfExistingOrder
So I should do something like this
Function getidsOfExistingOrder() As something
End Function
What is that something?
I look that HashSet support some interface
ICollection<T>, IEnumerable<T>, IEnumerable, ISerializable, IDeserializationCallback, ISet<T>, IReadOnlyCollection<T>
None of which is appropriate
IReadOnlyCollection<T> seems good but only support count. I want to test if the HashSet also contains some string.
So how should I do this?
Related
I fully understand that a System.Array is immutable.
Given that, why does it have an Add() method?
It does not appear in the output of Get-Member.
$a = #('now', 'then')
$a.Add('whatever')
Yes, I know this fails and I know why it fails. I am not asking for suggestions to use [System.Collections.ArrayList] or [System.Collections.Generic.List[object]].
[System.Array] implements [System.Collections.IList], and the latter has an .Add() method.
That Array implements IList, which is an interface that also covers resizable collections, may be surprising - it sounds like there are historical reasons for it[1]
.
In C#, this surprise is hard to stumble upon, because you need to explicitly cast to IList or use an IList-typed variable in order to even access the .Add() method.
By contrast, since version 3, PowerShell surfaces even a type's explicit interface implementations as direct members of a given type's instance. (Explicit interface implementations are those referencing the interface explicitly in their implementation, such as IList.Add() rather than just .Add(); explicit interface implementations are not a direct part of the implementing type's public interface, which is why C# requires a cast / interface-typed variable to access them).
As a byproduct of this design, in PowerShell the .Add() method can be called directly on System.Array instances, which makes it easier to stumble upon the problem, because you may not realize that you're invoking an interface method. In the case of an array, the IList.Add() implementation (rightfully) throws an exception stating that Collection was of a fixed size; the latter is an exception of type NotSupportedException, which is how types implementing an interface are expected to report non-support for parts of an interface.
What helps is that the Get-Member cmdlet and even just referencing a method without invoking it - simply by omitting () - allow you to inspect a method to determine whether it is native to the type or an interface implementation:
PS> (1, 2).Add # Inspect the definition of a sample array's .Add() method
OverloadDefinitions
-------------------
int IList.Add(System.Object value)
As you can see, the output reveals that the .Add() method belongs to the Ilist interface.
[1] Optional reading: Collection-related interfaces in .NET with respect to mutability
Disclaimer: This is not my area of expertise. If my explanation is incorrect / can stand improvement, do tell us.
The root of the hierarchy of collection-related interfaces is ICollection (non-generic, since v1) and ICollection<T> (generic, since v2).
(They in turn implement IEnumerable / IEnumerable<T>, whose only member is the .GetEnumerator() method.)
While the non-generic ICollection interface commendably makes no assumptions about a collection's mutability, its generic counterpart (ICollection<T>) unfortunately does - it includes methods for modifying the collection (the docs even state the interface's purpose as "to manipulate generic collections" (emphasis added)). In the non-generic v1 world, the same had happened, just one level below: the non-generic IList includes collection-modifying methods.
By including mutation methods in these interfaces, even read-only/fixed-size lists/collections (those whose number and sequence of elements cannot be changed, but their element values may) and fully immutable lists/collections (those that additionally don't allow changing their elements' values) were forced to implement the mutating methods, while indicating non-support for them with NotSupportedException exceptions.
While read-only collection implementations have existed since v1.1 (e.g, ReadOnlyCollectionBase), in terms of interfaces it wasn't until .NET v4.5 that IReadOnlyCollection<T> and IImmutableList<T> were introduced (with the latter, along with all types in the System.Collections.Immutable namespace, only available as a downloadable NuGet package).
However, since interfaces that derive from (implement) other interfaces can never exclude members, neither IReadOnlyCollection<T> nor IImmutableCollection<T> can derive from ICollection<T> and must therefore derive directly from the shared root of enumerables, IEnumerable<T>.
Similarly, more specialized interfaces such as IReadOnlyList<T> that implement IReadOnlyCollection<T> can therefore not implement IList<T> and ICollection<T>.
More fundamentally, starting with a clean slate would offer the following solution, which reverses the current logic:
Make the major collection interfaces mutation-agnostic, which means:
They should neither offer mutation methods,
nor should they make any guarantees with respect to immutability.
Create sub-interfaces that:
add members depending on the specific level of mutability.
make immutability guarantees, if needed.
Using the example of ICollection and IList, we'd get the following interface hierarchy:
IEnumerable<T> # has only a .GetEnumerator() method
ICollection<T> # adds a .Count property (only)
IResizableCollection<T> # adds .Add/Clear/Remove() methods
IList<T> # adds read-only indexed access
IListMutableElements<T> # adds writeable indexed access
IResizableList<T> # must also implement IResizableCollection<T>
IResizableListMutableElements<T> # adds writeable indexed access
IImmutableList<T> # guarantees immutability
Note: Only the salient methods/properties are mentioned in the comments above.
Note that these new ICollection<T> and IList<T> interfaces would offer no mutation methods (no .Add() methods, ..., no assignable indexing).
IImmutableList<T> would differ from IList<T> by guaranteeing full immutability (and, as currently, offer mutation-of-a-copy-only methods).
System.Array could then safely and fully implement IList<T>, without consumers of the interface having to worry about NotSupportedExceptions.
To "Add" to #mklement0's answer: [System.Array] implements [System.Collections.IList] which specifies an Add() method.
But to answer why have an Add() if it doesn't work? Well, we haven't looked at the other properties, i.e. IsFixedSize :
PS > $a = #('now', 'then')
PS > $a.IsFixedSize
True
So, a [System.Array] is just a [System.Collections.IList] that is a Fixed Size. When we look back at the Add() method, it explicitly defines that if the List is Read-Only or Fixed Size, throw NotSupportedException which it does.
I believe the essence is not, "Let's have a function that just throws an error message for no reason", or to expand on it, No other reason than to fulfill an Interface, but it actually is providing a warning that you are legitimately doing something that you shouldn't do.
It's the typical Interface ideas, you can have an IAnimal type, with an GetLeg() method. This method would be used 90% of all animals, which makes it a good reason for implementing into the base Interface, but would throw an error when you use it against a Snake object because you didn't first check the .HasFeet property first.
The Add() method is a really good method for a List Interface, because it is an essential method for Non-Readonly and Non-Fixed length lists. We are the ones being stupid by not checking that the list is not IsFixedSize before calling an Add() method that would not work. i.e. this falls into the category of $null checks before trying to use things.
Apologies if I am making some amateur mistakes, but I am new to VBA.
I'm trying to populate an array declared inside of a class as a property, but something's going wrong. After much searching I have two questions that I can't seem to find anywhere else:
1 - Is there a simpler way to accomplish saving data to an array-like structure that I can pass to functions from a sub? The array-like structure needs to be resizable because I will not know how many components I will add until each iteration of a loop checks those conditions.
2 - How do I correctly accomplish the passing of the array property in my class correctly to another function? It's frustrated me enough that I would like to know how it can be done if only to understand what I was doing wrong or, perhaps, what misunderstanding I had of the way VBA works.
Code structure follows:
I have declared a Segments property inside of a CTask class like this:
Private pSegments() As CSegment
Public Property Get Segments() As CSegment()
Segments = pSegments()
End Property
Public Property Get segment(index As Integer) As CSegment
segment = pSegments(index)
End Property
Public Property Let Segments(Value() As CSegment)
pSegments() = Value()
End Property
I pass the CTask from a Sub, where it is defined to populateTasks using this code:
Dim tasks() As CTask
ReDim tasks(1 To 10)
Call populateTasks(tasks)
When I do this, the populateTasks code receives it using the following code:
Function populateTasks(ByRef tasks() As CTask)
I then try to call another function from populateTasks called populateSegments like this:
Call populateSegments(tasks(icount).Segments)
I receive segments array inside populateSegments like this:
Function populateSegments(ByRef Segments() As CSegment)
The last two code snippets are where the problem resides. The segments array is populating correctly inside the populateSegments function, but when I check the array to see if it is empty just below the call to populateSegments there isn't anything in the tasks(icount).segments array. Thanks in advance for any help, and please let me know if more information is required.
Couldn't you make populatesegments a method of cTask? That avoids the problem and is a better design
I'm wrapping up my ajax copy & paste with explicit error reporting.
The final Function Returns three Keys with three Lists as Values.
psuedo
Return New Dictionary(Of String, List(Of Object)) From {
{"duplicatePoints", UniqueErrorsReport},
{"inexistentPoints", ExistenceErrorsReport},
{"insertedRows", InsertedRows}
}
Two are List(Of Object)s and one is a List(Of Array). I hate doing the same thing twice, so I'd prefer not to use a Structure.
I acted all smart and thought by declaring a List(Of Array) rather than a List( Of Object()) would let me slide since Array descends from Object (if I'm reading it correctly). Nope, at least not the way I'm doing it:
Unable to cast object of type 'System.Collections.Generic.List`1[System.Array]'
to type 'System.Collections.Generic.List`1[System.Object]'
Is it possible to avoid using a Structure and simply Return containers of both non-multidimensionals and multidimensionals as Values in the same Key: Value container?
Is it possible to avoid using a Structure and simply Return containers of both non-multidimensionals and multidimensionals as Values in the same Key: Value container?
No, this is not possible. You have to convert your array to a list or your lists to array.
This is like if you try to store integers and strings in the same List(Of String).
You can not have different datatypes in the same Generic.List.
Unless you have dynamic results I would try to avoid using a dictionary here, and rather use a custom, class (like below):
Public Class ErrorReport
Public DuplicatePoints as List(Of UniqueErrorsReport)
Public InexistentPoints as List(Of ExistenceErrorsReport)
Public InsertedRow as List(Of InsertedRow)
End Class
I would highly recommend against List(Of Object), because they cost you performance (boxing and unboxing) and the more important reason: it is prone to errors because you can not detect errors in compile time.
In a controller I have two values:
public List<String> StringValue {get; set;}
public List<String> ListValue {get; set;}
The ListValue is initialized in the constructor and several strings are added. At this point in a value I can refer to these with {!StringValue} and {!ListValue[1]} in a VisualForce page. The list one in particular is the focus - I can even add pseudo-constants (getters) as indexes, making {!ListValue[nameIndex]} a valid reference.
However I've run into an exception when trying to set a list value instead of a simple string value.
<apex:param value="123" assignTo="{!ListValue[1]}" />
The exception is java.lang.ClassCastException: java.lang.String cannot be cast to common.formula.FormulaFieldReference
I think I understand the basics of the problem - Salesforce can't create a setter reference that includes an index parameter (meaning only setters that take a single parameter can be referenced).
Is there any way around this, or do I just have to create a massive amount of ListValue1, ListValue2 variables and associated code?
It's a hack, but it avoids you having to create dozens of variables.
<apex:param value="1:123" assignTo="{!smartAssigner}" />
Then in your controller:
public void setSmartAssigner(String myval) { // parse the colon, set list value appropriately.
You get the idea.
I've never come across a way to do this in the style you're requesting, I'd suggest that to get this going the easiest thing to do would be to concatenate the values you want into one parameter and then split them back up inside the controller.
You might find a suitable way to do this with <apex:repeat> but I'm not sure on your full use case.
We have lots of immutable value objects in our domain model, one example of this is a position, defined by a latitude, longitude & height.
/// <remarks>When I grow up I want to be an F# record.</remarks>
public class Position
{
public double Latitude
{
get;
private set;
}
// snip
public Position(double latitude, double longitude, double height)
{
Latitude = latitude;
// snip
}
}
The obvious way to allow editing of a position is to build a ViewModel which has getters and setters, as well as a ToPosition() method to extract the validated immutable position instance. While this solution would be ok, it would result in a lot of duplicated code, especially XAML.
The value objects in question consist of between three and five properties which are usually some variant of X, Y, Z & some auxiliary stuff. Given this, I had considered creating three ViewModels to handle the various possibilities, where each ViewModel would need to expose properties for the value of each property as well as a description to display for each label (eg. "Latitude").
Going further, it seems like I could simplify it to one general ViewModel that can deal with N properties and hook everything up using reflection. Something like a property grid, but for immutable objects. One issue with a property grid is that I want to be able to change the look so I can have labels and textboxes such as:
Latitude: [ 32 ] <- TextBox
Longitude: [ 115 ]
Height: [ 12 ]
Or put it in a DataGrid such as:
Latitude | Longitude | Height
32 115 12
So my question is:
Can you think of an elegant way to solve this problem? Are there any libraries that do this or articles about something similar?
I'm mainly looking for:
Code duplication to be minimized
Easy to add new value object types
Possible to extend with some kind of validation
Custom Type Descriptors could be used to solve this problem. Before you bind to a Position, your type descriptor could kick in, and provide get and set methods to temporarily build the values. When the changes are committed, it could build the immutable object.
It might look something like this:
DataContext = new Mutable(position,
dictionary => new Position(dictionary["lattitude"], ...)
);
Your bindings can still look like this:
<TextBox Text="{Binding Path=Lattitude}" />
Because the Mutable object will 'pretend' to have properties like Lattitude thanks to its TypeDescriptor.
Alternatively you might use a converter in your bindings and come up with some kind of convention.
Your Mutable class would take the current immutable object, and a Func<IDictionary, object> that allows you to create the new immutable object once editing completes. Your Mutable class would make use of the type descriptor, which would create PropertyDescriptors that create the new immutable object upon being set.
For an example of how to use type descriptors, see here:
http://www.paulstovell.com/editable-object-adapter
Edit: if you want to limit how often your immutable objects are created, you might also look at BindingGroups and IEditableObject, which your Mutable can also implement.
I found this old question while researching my possible options in the same situation. I figured I should update it in case anyone else stumbles on to it:
Another option (not available when Paul offered his solution since .Net 4 wasn't out yet) is to use the same strategy, but instead of implementing it using CustomTypeDescriptors, use a combination of generics, dynamic objects and reflection to achieve the same effect.
In this case, you define a class
class Mutable<ImmutableType> : DynamicObject
{
//...
}
It's constructor takes an instance of the immutable type and a delegate that constructs a new instance of it out of a dictionary, just like in Paul's answer. The difference here, however, is that you override the TryGetMember and TrySetMember to populate an internal dictionary that you're eventually going to use as the argument for the constructor-delegate. You use reflection in order to verify that the only properties that you're accepting are those that are actually implemented in ImmutableType.
Performance wise, I wager that Paul's answer is faster, and doesn't involve dynamic objects, which are known to put C# developers into fits. But the implementation for this solution is also a little simpler, because Type Descriptors are a bit arcane.
Here's the requested proof-of-concept / example implementation:
https://bitbucket.org/jwrush/mutable-generic-example
Can you think of an elegant way to solve this problem?
Honestly, you just dance around the problem, but don't mention the problem itself ;).
If I correctly guess your problem, then the combination of MultiBinding and IMultiValueConverter should do the trick.
HTH.
P.S. BTW, you have immutable class instances, not value objects. With value objects (which are described by struct keyword) you would dance much more no matter if there were setters or not :).