Wiki

{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

def bar

pass

get baz as int

return 1

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

def main is shared

x = 2 to dynamic? assert (x to int) in [1, 2, 3] # works assert x in [1, 2, 3] # error: Cannot convert type "int?" to "int"


#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?


Note: See TracReports for help on using and creating reports.