Is there any way for me to maintain the order of declaration when iterating the items in NamedDomainObjectContainer?
As I understand right now NmaedDomainObjectContainer is using SortedSet as its implementation. I'm wondering if there is any LinkedHashSet version of it.
No, there is no way to maintain order of declaration.
Related
In my project I have many collection (slices) of different data types. Any particular collection should define fields it can sort by. I want to write one sort function and call it with user input (sort field and order) whenever collection should be sorted. I came up with the following boilerplate code (described only one type of collection, but for others it will be the same): https://gist.github.com/abonec/f1ee23a38e78ea48d470c39885de47ba
I have an interface Sortable for collections. Sortable should be passed to the sortStats with user input of sort field. If concrete implementation supports this type of sort it should return sort.Interface with corresponding interface.
Problem with many repeated implementations of sort.Interface where Len() and Swap() method is identical. Different is only Less().
Is there any approach to get a rid of Len() and Swap() methods in this case or may be other approach to write generic sort function with dynamic sort field?
You're looking for generics, which Go doesn't currently support. See this FAQ entry.
The Go team is working to add generics to the language - it's a work in progress, and everyone is free to participate in the discussion. Once generics exist, they will provide the solution you seek here.
In the meantime, you could use code generation or think of a slightly different design for your problem. Some code duplication is OK too, Go doesn't frown upon it as badly as some other languages.
I'm trying to make an array-like data structure in Scheme, and since I need to refer to it (and alter it!) often, I want to give it a name. But from what I've read on various tutorial sites, it looks like the only way to name the list for later reference is with define. That would be fine, except it also looks like once I initialize a list with define, it becomes more complicated altering or adding to said list. For example, it seems like I wouldn't be able to do just (append wordlist (element)), I'd need some manner of ! bang.
Basically my questions boil down to: Is define my only hope of naming a list? And if so, am I stuck jumping through hoops changing its elements? Thanks.
Yes, define is the way for naming things in Scheme. A normal list in Scheme won't allow you to change its elements, because it's immutable - that's one of the things you'll have to learn to live with when working with a functional data structure. Of course you can add elements to it or remove elements to it, but those operations will produce new lists, you can't change the elements in-place.
The other option is to use mutable lists instead of normal lists, but if you're just learning to use Scheme, it's better to stick to the immutable lists first and learn the Scheme way to do things in terms of immutable data.
Yes, define is the way to do "assignment" (really naming) in Scheme. Though, if you're writing some kind of package, you might consider wrapping the whole thing inside of a function and then using let to define something you refer to.
Then, of course, you have to have some sort of abstraction to unwrap the functions inside of your "package."
See SICP 2.5 Building Systems with Generic Operations
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-18.html#%_sec_2.5
(append wordlist (element)) is creating a new list. What you might want is to use set! to redirect a reference to the new list, or define a reference to the new list using the same symbol's name.
I have an array of custom classes. I've defined <=> on them, and have tested to make sure that my custom definition behaves as it should. I assumed that I could then call [].uniq and have it filter out my duplicates, but that isn't happening. Is there another operator I need to overload?
Array#uniq is based on equality, not on ordering, so your objects need to respond to eql?. Also, it uses hashing to speed up performance, so you need to implement hash as well.
Unfortunately, this contract isn't specified in the documentation, but it usually is specified in pretty much every Ruby book or course.
What I needed to implement, was .hash
I have a Core Data entity with four boolean non-optional properties, defaulted to NO. A class gets the entity object when the class is initialized, so this is not a result of an NSFetchResquest, and one of these four properties will be set to YES.
The class needs to know which property is YES.
Of course, I can use nested IF/Else statements (or ternaries) to find out which property is YES, but I'm wondering if there is a better (meaning more cocoa-ish) way to look at the entity and say 'is there a boolean value YES in your properties?'.
also, i can remodel to have the booleans have no value as default, and only look for the boolean that has YES, but that seems the same question.
Well there are several different possibilities. Using four different boolean properties is a clean solution. You then have to use the if ... elsif statements to find out what happened.
A more C way of doing that would be to define bitmasks which can be OR'ed together and stored as an NSUInteger. If this would semantically makes sense you could group them together in an enum, but that is the C way.
You could also define a custom subclass of NSManagedObject and write some convenience methods to check these options. Depends a bit on what they are good for.
You could use reflection (e.g., class_copyPropertyList and class_getProperty) to check what properties the class has, and examine their values, but that's a pretty heavy-handed approach when you already know which four properties are relevant. I wouldn't suggest this approach, and I wouldn't call it more Cocoa-ish, just more abstracted.
If you're looking at specific combinations of states, I think GorillaPatch's suggestion is right: You would turn those four booleans into a single 4-bit integer and compare it against bit masks representing the various combinations you're interested in.
Update: Please read this question in the context of design principles, elegance, expression of intent, and especially the "signals" sent to other programmers by design choices.
I have two "views" of a set of objects. One is a dictionary/map indexing the objects by a string value. The other is a dictionary/map indexing the objects by an ordinal (ordering integer). There is no "master" collection of the objects by themselves that can serve as the authoritative source for the number of objects, but the two dictionaries should always both contain references to all the objects.
When a new item is added to the set a reference is added to both dictionaries, and then some processing needs to be done which is affected by the new total number of objects.
What should I use as the authoritative source to reference for the current size of the set of objects? It seems that all my options are flawed in one dimension or another. I can just consistently reference one of the dictionaries, but that would codify an implication of that dictionary's superiority over the other. I could add a 3rd collection, a simple list of the objects to serve as the authoritative list, but that increases redundancy. Storing a running count seems simplest, but also increases redundancy and is more brittle than referencing a collection's self-tracked count on the fly.
Is there another option that will allow me to avoid choosing the lesser evil, or will I have to accept a compromise on elegance?
I would create a class that has (at least) two collections.
A version of the collection that is
sorted by string
A version of the
collection that is sorted by ordinal
(Optional) A master collection
The class would handle the nitty gritty management:
The syncing of the contents for the collections
Standard collection actions (e.g. Allow users get the size, Add or retrieve items)
Let users get by string or ordinal
That way you can use the same collection wherever you need either behavior, but still abstract away the "indexing" behavior you are going for.
The separate class gives you a single interface with which to explain your intent regarding how this class is to be used.
I'd suggest encapsulation: create a class that hides the "management" details (such as the current count) and use it to expose immutable "views" of the two collections.
Clients will ask the "manglement" object for an appropriate reference to one of the collections.
Clients adding a "term" (for lack of a better word) to the collections will do so through the "manglement" object.
This way your assumptions and implementation choices are "hidden" from clients of the service and you can document that the choice of collection for size/count was arbitrary. Future maintainers can change how the count is managed without breaking clients.
BTW, yes, I meant "manglement" - my favorite malapropism for management (in any context!)
If both dictionaries contain references to every object, the count should be the same for both of them, correct? If so, just pick one and be consistent.
I don't think it is a big deal at all. Just reference the sets in the same order each time
you need to get access to them.
If you really are concerned about it you could encapsulate the collections with a wrapper that exposes the public interfaces - like
Add(item)
Count()
This way it will always be consistent and atomic - or at least you could implement it that way.
But, I don't think it is a big deal.