EDT:Planning notes

This page provides a set of planning notes; in particular, for discussions on EDT validation rules.

13 September 2012

Attendees: Justin, Joe, Paul, Tim, Ben

Conclusion:

The EDT arrays continue to be called "lists," and the list type will have a new conversion operator... as ANY[], as INT[], and so forth.

the element type is explicit. the element is strongly typed.

(The rest of these notes reflect the conversation that led to the above conclusion but touched other issues.)

Delegates with type compatibility. More strict in the branch than in 0.8.1. The situation is, when comparing two delegates that are the same signature but are different delegates, they are different. But if delegate 1 has delegate 2 as a parm and if delegate 2 has ...

two records with the same structure are not compatible. so shouldn't these be the same?

we have name compatibility. can you cast from one delegate type to another if the signatures match? no, casting means that a conversion is possible at all. structure compatibility is done in pascal and elsewhere.

stay strict until we have a reason to be open. the ruiwidgets has this exact case: two different delegates. do we generate anything for a delegate that would make a delegate type.

a delegate should not be a generated artifact. for that reason, we can choose to be looser or not. the compat rule between a function and a delegate is loose: is by signature, not by name. you'd think the delegate would be the same. so... let's make it work like funciton.

we want parms of type delegate to follow the same rule.

IDE extensibility. the utilities will use the old model? no. remove the old model. paul is working on content assist. he says, "we have these enumeration and system-library managers set up by the system environment. i didn't migrate those pieces..."

content assist should have nothing special in its processing than other lookups. the system parts were not indexed before. system parts will always be parts that are resolvable.

IDE extensibility. i have an extension point. you now have a command line parm to use an extension.

a syntactic issue about assigning arrays to arrays. the dataGrid expects an ANY array, and you assign an ANY array of customer; but one way to solve the problem is by having a specialization of mutable versus immutable arrays. if the system knows about immutability, it's a different type.

in dataGrids, do people add columns on a fly? we need a rationale. dictionaries lets you put anything there, and no one cares if you assign one dictionary to another -- no issues about element type. anything in that dictionary is really an ANY.

what we really need is an array that works like that. let List be a real type. what is the difference between ANY array and List? The difference is, if you assign a variable to type list and assign an arbitrary list, there are no restrictions on what you can put into it.

So the DataGrid is of type List. You have to know what you are putting in there and nothing will enforce the type. Dynamism is retained. An array of 1,2 assigned to an int array: still should work. A different literal syntax for a list versus array. "as List"? Sounds right. Alternatively, have a List constructor that suupports any number of arguments?

In the generated Java code, it's always a list of objects. Implementation of List and Array is the same. Is the same class.

x any [] = [ 1, 2 ];

y List (from egl.lang.EList) = [1, 2] as any[]

z int[]

y = z

y.addElement("abc")

appendElement, getElement, etc: you must use an interface for access, or ::, but not indexes.

how to syntactically declared an occurred thing: how to declare a fixed occurred element of type int.

x[3] int; it's an element named x that occurs 3 times. this is not an array: no array object. just a way of stating and referencing something that is a value. could be occurs of string.

x[3] string; a copy of all occurred elements.

occurred elements are fixed size: a static number of elements in the ordered set.

back to the arrays. we need a solution to assignment between lists. we have to allow grids to take arbitrary lists. just having an arbitrary list of things that have no type restriction, as we said earlier.

MOVE is our copy operation, by the way.

The problem with MOVE is that you can't use it inside of an initializer. In EGL, List is a different type than EList.

you can't assign an int array to an any array.

an array of specific records can't be cast as an any array. as operation between lists of different types just forces a copy.

need a conversion operation in EList that takes another typed list and does the conversion of every element.

x any[] = [1,2] is not compatible. x list = [1,2] as any ... will work. no! we do not use the name List after all... and arrays are called lists.

list type will have a new conversion operator... as ANY[]. as INT[].

the element type is explicit. strongly typed.

language elements in bugzilla. finalize the language for the .9 release.

object-oriented EGL by December.

validation: core. how about validation for extensions. "done" says Justin. that's how we proved that they are extensible. Rich UI hasn't been separated out yet. Are we separating out RUI from core? We may choose to package it, fine, but not now.

EGL parts need to be pulled out in a separate eglar. separate EUnit out of the core. EUnit tests aren't even out there. JavaObject and JavaObjectException... are not part of core. We are splitting Java out of core.