{5} Accepted, Active Tickets by Owner (Full Description) (8 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
Chuck (5 matches)
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#1 | Extension methods and properties | Cobra Compiler | Cobra 0.9 | enhancement | 03/10/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Support extension methods and properties on existing classes, interfaces and structs whether they come from DLLs or declarations. This feature is found in Smalltalk, Objective-C (categories), C#, VB and others. C# and VB do it on .NET 3.5, but Cobra is still targeting 2.0 and will support it there. The syntax will be: extend Foo
One interesting question is whether or not to allow a nil receiver. C# does which, imo, is quite strange. For "obj.Foo()" in C# you need to know if Foo() is declared in obj's type or outside of it to know whether or not you can pass nil. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#107 | Syntactic relaxation: Type declaration clauses | Cobra Compiler | Cobra 0.9 | enhancement | 12/21/08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Outlined in http://cobra-language.com/forums/viewtopic.php?f=4&t=225 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#126 | Provide enumerate method (or similar) in CobraCore | Cobra Compiler | enhancement | 01/06/09 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Once you have multi arg assignment in for loops it seems its a common idiom to want to walk an IEnumerable and get back an item and its offset in the IEnumerable Currently to do this you need to wrap a counter around the IEnumerable forloop i as int = 0 for item in mylist doSomethingWith(i, item) i += 1 While not difficult this is tedious and obscurative and generally 'clunky' In python this is provided with an .enumerate function myList = [ 'one", 'two', 'three'] for i, item in enumerate(myList) doSomethingWith(i, item) I propose we add a similar method to CobraCore allowing something like myList = [ 'one", 'two', 'three'] for i, item in CobraCore.enumerate(myList) doSomethingWith(i, item) Pending pure functions or some form of default method lookup to a specified class ( CobraCore ) this is probably as simple as we can get.... Heres the implementation def enumerate(ie as IEnumerable) as IEnumerable<of IList> is shared n=0 for e in ie yield [n, e] n += 1 def main is shared a = [1,2,3,4] l = .enumerate(a) l1 = for ii in l get ii assert l1 == [[0,1],[1,2],[2,3],[3,4]] for i,item in .enumerate(['a','b','c']) assert i in [0,1,2] assert item in ['a', 'b', 'c'] #print "[i]:[item]" kvpList = [KeyValuePair<of String, String>('x','aa'), KeyValuePair<of String, String>('y','bb'), KeyValuePair<of String, String>('z','cc') ] for i,kv in .enumerate({'x':'aa','y':'bb','z':'cc'}) assert i in [0,1,2] assert kv in kvpList #print "[i]:[kv]" |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2 | Cannot use "x in someList" where x is dynamic? | component1 | defect | 03/16/08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
class X
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#41 | False warning for if statement on box var | Cobra Compiler | defect | 09/03/08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
class X def main is shared x = X() x.compute var _foo as X? def compute if _foo .bar if _foo # false warning here since .bar can change _foo .bar def bar _foo = nil The warning is: foo.cobra(12): warning: The expression "_foo" (of type "X") will always evaluate to true because it is not nilable. You can remove the expression. This is low priority as it comes up rarely. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
jonathandavid (3 matches)
Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#130 | The compiler doesn't find the "closest" extension method | Cobra Compiler | Cobra 0.9 | defect | 01/08/09 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Test case: # x-extend.cobra class A pass class B inherits A pass class C inherits B pass extend B def n as int return 2 extend C def n as int return 3 class P def main is shared b = B() assert b.n == 2 c = C() assert c.n == 3 Cobra takes the first extension method it can find instead of the closest among all available. Also, this bug is blocking further extensions being added to Cobra.Lang\ExtendIEnumerable.cobra |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#145 | complete the collection of string.split extension methods | Cobra Compiler | enhancement | 02/05/09 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
.NET's core string class has versions that take the separators as a char[]. Cobra's January 09 update adds extension methods that take a List<of char> separator instead, which is more convenient. Currently missing: * All the versions that take the max. number of tokens in addition to the separators. * Versions that take the separator as a string (this is the easiest to use). * Versions that take the separator as char* (this is the most generic way, the more specific ones would be left mainly for efficiency). The char* version would probably lead us to remove the one that currently takes a IList<of T>. See forum thread: http://cobra-language.com/forums/viewtopic.php?f=4&t=292&p=1727#p1727 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#149 | Simplifying internal class VariType | Cobra Compiler | enhancement | 02/10/09 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Right now, objects of VariType read from a CLR DLL have the following structure. VariType[T] = NilableType[ArrayType?[T]] The Class[T] notation I've just made up means that Class inherits from WrappedType, and has T as its _wrappedType instance var. (Note that native Cobra vari params don't have this problem, as they are created with the much more logical structure VaryType?[T] = T) I see one problem with the structure above, namely that ArrayType? layer is redundant; it should be implicit from the fact that we are dealing with a vari parameter. In a previous ticket I objected to the NilableType part as well, but once we remove the ArrayType? layer we will be left with: VariType[T] = NilableType[T] Now I think that this makes sense, since the arguments passed as vari parameters can be nil. For example: "1 2".split(@[1, nil]) The goal of this ticket, thus, is to change the way vari params are read from CLR DLLs, so that the ArrayType? layer is not added. 2) The NilableType part is mislocated As you can imagine, the code to extract the T from a VariType31 gets quite convoluted. Why not have VariType32 as VariType33[T] = WrappedType34[T]? If case some of the functionality of ArrayType??35 is needed, why not have VariType36 inherit from ArrayType??37? And most important, why put that Nilable layer in the middle? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||