​​
​​On Wed, Jan 11, 2017 at 3:57 PM, 'Terry Brown' via leo-editor <
[email protected]> wrote:

​> ​
I'm not sure if that can be a blanket statement.  I guess Leo doesn't have
a defined boundary between declared API and internals subject to change -
perhaps by default we've assumed the stable API is *everything*, that *no*
changes should break existing code. But I'm sure that doesn't reflect
reality, every time a helper function is eliminated or something like that
there's a chance to break someone's code, somewhere.

​Yes, there is some wiggle room.  But not for the text wrappers ;-)

Happily, we are not stuck with using text wrappers in all situations, or
any other part of the api.
​ ​
We can always invent new code.

For example, I am busy​ gutting Leo's syntax coloring code. The old code
will go away when the pyzo switch is true in leoColorizer.py. I don't feel
any constraints in doing so, except that c.recolor, c.recolor_now and
c.outerUpdate methods should continue to work as before.

​> ​
But what about things like the free_layout framework.  I'd like to remove
it and replace it with Qt Docking, I've been working on that, not ready to
release yet, or even close, but do we really need to worry about scripts
that might be broken by such a change?

​You are quite right.  There must be room to maneuver.

This is a judgement call.

I think we will both agree that we won't want to change methods that define
user-visible commands.  Unless we are going to remove those commands ;-)

Iirc, there is no list of official ivars, except in one or two unit tests.
Again, we can agree the following will never be removed:

c, c.frame, c.frame.body, c.frame.body.wrapper and
c.frame.body.wrapper.widget.  And a few others.

​> ​
How many people would have interacted with that code?

​That's the important question.  Whenever possible, we will probably want
to leave old code in place, or make everything work *as if* the old code
was in place. We want to extend API's, not change them.

​> ​
Tricky.

​Yes.  But there are clear ways forward.  We remain compatibility with
common API's when possible.  Most importantly, we communicate the issues
and our intentions to all who may be affected, and listen to their concerns.

Edward

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to