Good evening Clinton and Jafar, I'll bring both of your responses into a single response and then detail my provisional plans.
On 04/06/15 15:13, Jeffery, Clint ([email protected]) wrote: > Bruce, > > I commend you for looking at this. I have been wanting to merge in Steve's > libraries for a long time. Your analysis is spot on. We want to not > duplicate the overlapping parts, but we want to preserve backward > compatibility, and the goals conflict. > > My advice is: the problem as posed is too big. Find small pieces that we can > manage to merge successfully, that are non-conflicting and/or self-contained > if possible. Let's do some of those and actually get them into the public > Unicon distribution, we will gain experience points and levels from that. I was somewhat unclear with my initial message to the group. I want to start looking at class Class (and by inference class Object) and see what can be done to provide a unified set of facilities that can be used in all currently available code (unicon library and UniLib library). Both Robert and Steve (and in my own code base) have provided a number of ways to access the class hierarchy, methods, fields, etc. My initial look will be to merge the specific classes into a single parent that can be used a base class for all classes developed. From what I can see, there are various sections of the unicon library that don't use the class Class or class Object in their hierarchy. These (as far as I can tell) won't be affected by anything that I do. As a result of some code conversion I am doing from both python and javascript, I have developed a couple of classes that essentially give me the same kind of facilities as found in both languages to allow me to migrate the specific projects into unicon. In doing so, I started investigating the unicon libraries and noticed that some of the facilities I had been developing were similar to what already existed. But I have additional requirements as well as don't use all the available facilities (which in retrospect I could use). > For bigger, conflicting and overlapping classes and packages, we get into > technical details and careful considerations. Probably this group is not the > place for that, we almost need a separate mailing list or working committee. Agreed. I have a couple of ideas that need scrutiny. I implement the protocol myself and I can see it having some application in various sections of the unicon library, particularly the IDE and GUI sections. But that is for another time. > > Cheers, > Clint > > On 04/06/15 13:44, Jafar Al-Gharaibeh wrote: > Greeting Bruce, > > It is really hard to tell how this is going to affect people if we > don't know what is going to change. I can tell you that the gui class > library is widely used inside and outside the Unicon sources. Any > change should be backward compatible or at least we have to resolve > any code conflict very very carefully. People might also be using some > features indirectly so there might be a ripple effect there. Of course > any attempt to merge/simplify the code is going to be welcomed by > everyone, especially those who maintain the code, as long as it > doesn't break existing programs. At this point, I don't have any idea of the scope of changes. As I responded to Clinton above, my initial area is the facilities at the top of the class hierarchy. In terms of existing programs, I don't know what people are using outside of the existing unicon distribution. That is why I made the request. To gain some understanding of what people might be using from the IPL and the unicon class library. As Clinton did previously, a new library was created and the unicon distribution moved to using that version, with the old version available until it could be determined that it wasn't in use anymore. > > Can you tell us what code are you changing? and how ? what patches are > you proposing? this will allow us to give you better feedback. See my comments to Clinton above. > > Regards, > Jafar > > regards Bruce Rennie ------------------------------------------------------------------------------ _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
