Re: LeoU: Formal code review of vnode class

On Mon, Apr 30, 2018 at 7:16 AM, Terry Brown wrote: The perception of productivity is probably partly tied to cost - > discussions like this and previous similar ones often consume 100% of > the time I have available to work on Leo in a day, so they need > valuable

Re: LeoU: Formal code review of vnode class

​​ On Sun, Apr 29, 2018 at 1:51 PM, vitalije wrote: ​Ok. This is the "long" response that I promised in two other responses I have just written in this thread.​ It's really too long, but I want to discuss all the details just once. This will be pre-writing for a much short

Re: LeoU: Formal code review of vnode class

On Mon, 30 Apr 2018 05:07:05 -0500 "Edward K. Ream" wrote: > > Finally though another point that I think Vitalije also touches on - > > these discussions are not unhealthy, but they're not really > > productive either, unless there's serious interest in major > >

Re: LeoU: Formal code review of vnode class

On Mon, Apr 30, 2018 at 5:50 AM, vitalije wrote: > >> Have you looked in the code examples I gave in my previous message. >> > ​No, I haven't. ​ > Moving gnxDict from c.fileCommands to VNode itself and keeping >> c.fileCommands.gnxDict as a property that links to VNode

Re: LeoU: Formal code review of vnode class

> > > 1. It would be crazy to change the API of the Position and VNode classes. > The payoff would not remotely justify a fork in Leo's code base. *Do not > go there*.​ > > ​Imo, it is tragic that python decided to fork itself into python 3. The > pain will be eternal. There were other

Re: LeoU: Formal code review of vnode class

On Mon, Apr 30, 2018 at 2:13 AM, vitalije wrote: Because we are not sure what and where can be broken when we change > something, most often we are fixing bugs using just minor tweaks, adding > guards here and there, adding more kwargs. That strategy may suffice for a >

Re: LeoU: Formal code review of vnode class

On Sun, Apr 29, 2018 at 4:00 PM, Terry Brown wrote: >From a general design principle, I find it extremely jarring to need a > Commands object to instantiate a VNode. ​Interesting. This has never bothered me (before now). ​ > This is the (general) question > ​ ​ > of

Re: LeoU: Formal code review of vnode class

> > I don't think these issues are because Leo is badly designed or > implemented, I think it's because Leo's nearly twenty years old(?) and > has evolved, > Precisely. vertical integration between layers makes it hard to develop Leo, from the > point of view of understanding code flow and

Re: LeoU: Formal code review of vnode class

FWIW, I think I generally agree with Vitalije. First, seeing everyone's apologizing ;-) let me apologize for dragging an attempt at general discussion into the weeds of specifics, I know that's annoying. I know that the point doesn't rest on the particular history of uAs or VNodes or whatever.

Re: LeoU: Formal code review of vnode class

> > Oh my. I do apologize for distressing you. > There is no need that you apologize to me. In fact I am the one who has been rude. To me having most basic data element that can't be instantiated on its own is a big issue. While on the other side you think it is not a big deal. In the

Re: LeoU: Formal code review of vnode class

> > Well, I hope you mean, no more complaints about the VNode class ;-) To me it is obvious that we look at the same code and see quite opposite things. I feel like few last threads that I have started brought nothing good, and yet they made us both spend lots of time, perhaps even spoiled

Re: LeoU: Formal code review of vnode class

​​ ​On Sat, Apr 28, 2018 at 6:46 AM, vitalije wrote: ​​ > O.k. No more complains from me. > ​ Well, I hope you mean, no more complaints about the VNode class ;-) Please do continue to question Leo's design, code and style, or anything else. The last thing I want is to

Re: LeoU: Formal code review of vnode class

O.k. No more complains from me. Vitalije -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send

LeoU: Formal code review of vnode class

This post will be pre-writing for a LeoU issue. Recent discussions about Leo's design have stimulated this post. Here, I'd like to simulate a formal code review of Leo's vnode (VNode) class. I'll wear three hats: the