Re: Phix 1.0.2 uploaded

new topic     » goto parent     » topic index » view thread      » older message » newer message
jimcbrown said...
petelomax said...

It is likely to have significant breaking changes, in particular I am thinking of totally deprecating routine_id(), c_func(), c_proc(), and call_back() - but of course there would be 500+ working examples, and docs that fully explain what said need to be replaced with. In either case there will be a new way, whether compatibility can be maintained as well..

I'm kind of curious, why is such a move being considered?

Well, that code is really ugly, difficult to maintain, as Greg has recently found out there are loads of things it simply cannot cope with, and while you might rarely notice it the performance is actually pretty dreadful.
If I am to do a major update with a new target architecture, that is without any doubt at least according to my current way of thinking, going to be one of the very first things to get thrown into the rubbish bin.
Actually, that's the latter three, routine_id() is slightly different. Given that you can already code myfunc instead of routine_id("myfunc"), and no program should ever need, or in fact be encouraged, to stich together "my" and "func", it really is time to wave it goodbye. Plus I want the freedom to replace a flat symbol table with a nested tree structure, and a complete rewrite (of "routine_id") could well introduce a dirty great heap of possibly very subtle incompatibilites anyway.
Not much is really set in stone for 2.0 yet, but I need the right to choose the easiest route to get there.

Another argument is that if you deliberately break backward compatibility to the extent that almost nothing in The Archive still works, that might actually be the very excuse needed to pick through them one by one and either fix or bin them, and, why not, migrate any successes to a brand shiney new and hopefully much nicer 2.0+-only location, and perhaps even actually delete the by now utterly useless original.

PS the parse tree (etc) will likely still technically be a "flat" table, just one that needs a special traversal process rather than the traditional +1.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu