I whipped up a small sample class for storing a pair of values using `dynamic` (as opposed to alternatives such as `Object` or a generic).
As webnov8 pointed out, this is somewhat reminiscent of tuples, but I didn't take it that far.
See attached. Comments and questions are welcome.
Forums
Pair sample class
14 posts
• Page 1 of 2 • 1, 2
Pair sample class
- Attachments
-
- Pair.cobra
- (3.03 KiB) Downloaded 1008 times
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Pair sample class based on dynamic
Very neat. To make method tests less intrusive, you could consider adding an "assert" block where every statement gets asserted. Compare the current:
With:
def compareTo(p as Pair) as int
test
assert Pair('a', 'b') < Pair('b', 'c')
assert Pair(2, 3) > Pair(2, 2)
assert Pair(nil, 'a') < Pair(nil, 'b')
assert Pair(nil, nil) < Pair(1, 1)
body
diff = .compare(.a, p.a)
if diff == 0, diff = .compare(.b, p.b)
return diff
With:
def compareTo(p as Pair) as int
test
assert Pair('a', 'b') < Pair('b', 'c')
Pair(2, 3) > Pair(2, 2)
Pair(nil, 'a') < Pair(nil, 'b')
Pair(nil, nil) < Pair(1, 1)
body
diff = .compare(.a, p.a)
if diff == 0, diff = .compare(.b, p.b)
return diff
- jonathandavid
- Posts: 159
Re: Pair sample class based on dynamic
I have expanded on this with Pair<of T> and Pair<of TA, TB>. Like C#, Cobra allows class names to be overloaded based on the number of generic arguments. Comes in handy.
This can now be found under the Supplements directory in a Cobra workspace, and also browsed online:
http://cobra-language.com/trac/cobra/br ... Pair.cobra
Comments and questions are welcome.
This can now be found under the Supplements directory in a Cobra workspace, and also browsed online:
http://cobra-language.com/trac/cobra/br ... Pair.cobra
Comments and questions are welcome.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Pair sample class
I have added Pair<of T> and Pair<of TA, TB> to the Cobra standard library so that they are immediately available (just like List<of T>, Set<of T>, Dictionary<of TK, TV>, etc.). changeset:2730
I haven't decided to include the dynamic version at this point. It's not strictly necessary and Cobra may infer generic args on object creation at some point in the future, making it even less interesting. You can still copy it out of the Supplements directory and include it in your project if you want it.
I haven't decided to include the dynamic version at this point. It's not strictly necessary and Cobra may infer generic args on object creation at some point in the future, making it even less interesting. You can still copy it out of the Supplements directory and include it in your project if you want it.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Pair sample class
What is "Repeated Pair<of>"?
class X
def main
pairs = [Pair<of int>(1,2), Pair<of int>(3,4), Pair<of int>(1,2), Pair<of int>(3,4)]
trace pairs
# trace : pairs=List<of Pair<of int>>[Pair<of int>[1, 2], Pair<of int>[3, 4], (Repeated Pair<of int>), (Repeated Pair<of int>)]
# - at Test.cobra:6
# - in X.main
#Cobra svn:2738 (post 0.8) / 2012-07-08 on Mono 2.10.9 CLR v4.0.30319 on Mac OS X 10.6.8
- jaegs
- Posts: 58
Re: Pair sample class
This behavior comes from Cobra.Core.StringMaker which avoids repeating nested lists, dictionaries, etc:
It accomplishes this primarily by checking for IEnumerable, though it already makes an exception for String. I have added an exception for Pair. So this is fixed now.
class X
def main
t = [1, 2, 3, 4, 5, 6, 7, 8, 9]
trace [t, t]
/#
trace : [t, t]=List<of List<of int>>[List<of int>[1, 2, 3, 4, 5, 6, 7, 8, 9], (Repeated List<of int>)]
- at x-pairs.cobra:6
- in X.main
#/
It accomplishes this primarily by checking for IEnumerable, though it already makes an exception for String. I have added an exception for Pair. So this is fixed now.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Pair sample class
Do you think it's possible to make Pair<of T> a subclass of Pair<of T, T> ?
A method that takes a Pair<of TA, TB> won't accept Pair<of T> even though conceptually it should. Hence a second method that takes Pair<of T> is required. Pair<of T> quickly becomes more of an annoyance than a convenience.
A method that takes a Pair<of TA, TB> won't accept Pair<of T> even though conceptually it should. Hence a second method that takes Pair<of T> is required. Pair<of T> quickly becomes more of an annoyance than a convenience.
- jaegs
- Posts: 58
Re: Pair sample class
I'm about to step away so I can't try it now, but it certainly seems feasible:
I understand your complaint. Thanks for bringing this up.
I was contemplating making them structs but .NET disallows inheritance with structs. I suppose this would preclude that. I think the issue you bring up is the larger one, however.
class Pair<of T> inherits Pair<of T, T>
...
I understand your complaint. Thanks for bringing this up.
I was contemplating making them structs but .NET disallows inheritance with structs. I suppose this would preclude that. I think the issue you bring up is the larger one, however.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Pair sample class
In the future, I plan on investigating the inference of type args for object instantiation. For example, Pair(5, 's') instead of Pair<of int, String>(5, 's'). Wouldn't that be nice?
Sounds good. However unless there is some sort of literal syntax, I imagine that for personal use I would do something like
class P<of TA, TB> inherits Pair<of TA, TB>
pass
in order to do
lst = [P(c'a', 1), P(c'd', 5), P(c'e', 3)]
- jaegs
- Posts: 58
Re: Pair sample class
If we follow through on "alias", you could use that.
Also, this is intended for any generic class. It has been pointed out that C# will infer generic type args for methods but not for constructors which feels inconsistent. And not only is it less convenient, but it is a deterrent to making a non-generic class generic since it will break all object creations. Cobra has these same limitations.
Also, this is intended for any generic class. It has been pointed out that C# will infer generic type args for methods but not for constructors which feels inconsistent. And not only is it less convenient, but it is a deterrent to making a non-generic class generic since it will break all object creations. Cobra has these same limitations.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
14 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 10 guests