MUSHclient : Development : Scripting engine refactoring?

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
Development
Scripting engine refactoring?

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

Scripting engine refactoring?

Reply to this subject Start a new subject Refresh page

Pages: 1 2 3 4

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #15 on Tue 07 Sep 2010 06:24 AM (UTC) [ quote ]

Amended on Tue 07 Sep 2010 06:25 AM (UTC) by Twisol

Message

David Haley said:
What about your miniwindow system?

Still working on it off and on. Lua isn't the easiest language to do this in.

David Haley said:
I think the main point I have been trying to make is that features are more important than frameworks for features, and there are features that are needed -- like rich inventory list widgets, maps, and so forth.

I disagree. The groundwork for a feature is just as important as the feature itself, if it's to be stable and agile. The miniwindow API itself is such a framework, and it's fairly hard to use for anything beyond a certain complexity. Orthogonality (I've said this before) would be a huge plus, but it's too late to change. MWAPI (my thing) is supposed to help, but I'm stymied by the API even here.

Granted, I haven't made many production plugins using miniwindows, but that's because it's hard.

David Haley said:
Nick has very often talked about how nice it would be to have richer GUI environments, so even without having a whole framework for miniwindows, there is a lot of stuff that can be done.

The miniwindow API is the framework itself, and yes, there's a lot that can be done. Possibility is a very different thing from feasibility though.

David Haley said:
Maybe it'll be easy and Nick won't mind integrating it. =Your initial post made it sound not-so-easy. You said yourself you were trying to gauge interest; well, I'm just telling you that I don't think it's worth spending time on.

It would be no easier than my t_regexp changes. If that's going nowhere, I'm not really going to hold my breath on the script engine changes. Pessimistic? Maybe.

David Haley said:
Well, in my experience, people sometimes get that feeling because they're confusing complexity for cruftiness. Something of this size will always be complex. You said yourself that Aspect is a big task; perhaps if you were to bring it to the level of stability and feature-richness that MUSHclient has, you would appreciate better how necessarily complex some stuff gets.

There is a god object in the very core of the program. No sane person on Earth can call that good management of complexity. Everything, and I do mean everything, comes back to CMUSHclientDoc.

David Haley said:
Heck, part of the reason that you get weird tangled mazes of knots and interdependencies is precisely that there can be subtle links between apparently different components. Obviously not all such cases are necessary, but how do you quickly tell which are which?

You start by not having public data fields unless necessary, and work out from there. Encapsulation is a Good Thing (tm), and I am emphatically not the only one to think so.

David Haley said:
The point is just that it's his time to spend and I'm just trying to help you understand what you need to do to convince him that some task is worth undertaking. You sometimes act as if he never listens to you but that is demonstrably false if one looks at the suggestions forum; most recently he implemented the image rotation suggestion. Granted, he didn't implement everything you asked for, but he did take the suggestion and act upon it (and wrote the code, in this instance).

And I'm very grateful for that. It tends to come after a struggle, immediately after which I feel bad because I feel like I forced him into it. I just feel like I'm up against a brick wall when I'm the one doing the work.

Ask for things vs. do them yourself... gee, I honestly prefer the latter, but I seem to get my way more often with the former. That just makes me feel worse.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #16 on Tue 07 Sep 2010 10:54 AM (UTC) [ quote ]

Amended on Tue 07 Sep 2010 10:56 AM (UTC) by Twisol

Message

If you don't mind, I'm going to chronicle my progress on this, even if it never gets pulled into the source.

---

As with anything, I'm taking an iterative approach to this refactoring. I first tinkered with it in Notepad++ from scratch to get an idea of what to do, and then I started hacking around with the real deal to get a practical idea of the problem domain. Now I'm on to my third iteration, and hopefully my last. I believe I have a solid understanding of how to define IScriptEngine, so this iteration should turn out better than the last.

Just as CMUSHclientDoc implements an interface for the scripting engine to invoke, so IScriptEngine will define an interface for MUSHclient to invoke. Each "callback" style will have its own method defined in IScriptEngine, such as OnMXPClose and OnInstall. From an abstract perspective, these are really events that MUSHclient can notify an engine of. An engine is then free to react in any manner it wishes.

This is only part of the big picture, though. This will clean up the code, but it won't make it any easier to define a new engine that can use the CMUSHclientDoc scripting interface. This is because that interface is coupled very tightly with CMUSHclientDoc.

Once I've confirmed that the first refactoring works, I want to move the CMUSHclientDoc script interface out of CMUSHclientDoc, and relegate it to the same "layer" as the Lua glue functions. Effectively, the functionality would remain in CMUSHclientDoc, but the scripting "glue" is defined somewhere else, where it can be used specifically by the WSH engine.

With those two steps complete, I believe it should be far easier to manage, modify, and create scripting engines, and especially bind them more naturally to the client language. Fortunately I don't have to do them both at once, because I'm positive I'll need another set of iterations to go through with the script-interface refactoring. Still, I'm pretty confident in my battle plan thus far.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #17 on Tue 07 Sep 2010 03:04 PM (UTC) [ quote ]

Message

Quote:
Still working on it off and on. Lua isn't the easiest language to do this in.

Well, either way, it is something to do that would provide clear and immediate benefit, and allow people to go forward more easily in a direction Nick has advocated many times.

But, well, yes, sometimes the truly useful features to end-users and developers will be difficult.

Quote:
The miniwindow API itself is such a framework, and it's fairly hard to use for anything beyond a certain complexity.

Might I suggest that it's complex because the task itself is complex?

Honestly I would be interested to see what a client would look like if you designed it from scratch, and how you would make everything so simple.

Quote:
You start by not having public data fields unless necessary, and work out from there. Encapsulation is a Good Thing (tm), and I am emphatically not the only one to think so.

Nobody is disagreeing. People are only disagreeing about how necessary it is to go through big rewritings of things to encapsulate.

Quote:
Ask for things vs. do them yourself... gee, I honestly prefer the latter, but I seem to get my way more often with the former. That just makes me feel worse.

Well, I'd say that this is the case because in the former it just means that you sufficiently convinced him that it was a good idea that he implemented it himself, whereas in the latter he didn't do it himself usually because he didn't think it was sufficiently high on the priority list. (The priority list is w.r.t. time in general, not just a MUSHclient priority list.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #18 on Tue 07 Sep 2010 06:40 PM (UTC) [ quote ]

Message

David Haley said:
Well, either way, it is something to do that would provide clear and immediate benefit, and allow people to go forward more easily in a direction Nick has advocated many times.

But, well, yes, sometimes the truly useful features to end-users and developers will be difficult.

It's largely Lua that's making this hard on me; I think in objects, and Lua makes you build said objects from scratch. I honestly think it would be much easier to do in something like Ruby.

David Haley said:
Might I suggest that it's complex because the task itself is complex?

I'll grant you that, okay. Graphics programming is never the easiest thing. But it's rather funny that, without me knowing it, my API gravitated towards what GDI already does.

With MUSHclient there seems to be an "only one chance" thing going on. In general, once something's in you can never ever replace it. Huh, actually that does explain the "would rather work on new features", because if you never go back and redo things with what you've learned, you don't really need the flexibility. This, for once, isn't a complaint; it's just an observation.

David Haley said:
Honestly I would be interested to see what a client would look like if you designed it from scratch, and how you would make everything so simple.

Yeah, wouldn't we all... Usually I have ideas and I never execute them 100%. I really hope Aspect turns out differently. I just need to hop back in at some point.

I know I'm like the new kid here. Nick's probably been programming for several decades longer than I have, and you're probably not far off either. But I don't think I'm wrong here. (Whether I'm right is a different matter.)

David Haley said:
Nobody is disagreeing. People are only disagreeing about how necessary it is to go through big rewritings of things to encapsulate.

The "never improve old features" thing, right. At least now I understand it.

David Haley said:
Well, I'd say that this is the case because in the former it just means that you sufficiently convinced him that it was a good idea that he implemented it himself, whereas in the latter he didn't do it himself usually because he didn't think it was sufficiently high on the priority list. (The priority list is w.r.t. time in general, not just a MUSHclient priority list.)

There you go: he's basically the only one allowed to make changes. That's not a bad thing. I just think that, if he doesn't want me to contribute in big ways, he make that clear so I can do something that will be more useful to everyone. (Like MWAPI.)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #19 on Tue 07 Sep 2010 07:17 PM (UTC) [ quote ]

Message

Twisol said:
The "never improve old features" thing, right.

Well I wouldn't say "never". :-) However the bar is high, yes.

I like to think of it in dollar terms, even if the dollars are imaginary. How many dollars does it cost to change something vs. how many dollars would you save or make from the change?

FWIW, fighting the itch to go and rewrite crufty stuff is a big learning point for all programmers, myself included. I still fight it at work sometimes. Old code is old and crufty code is crufty, but it all works, and there's plenty of new stuff that needs to get written, even if it's sometimes boring or hard.

Of course, when the old stuff doesn't work, we fix it; if it's a big pain to deal with and causes clear confusion and trouble, we consider spending time to rewrite it. Perhaps caution is more evidently appropriate in this case, though, when a software mistake can potentially cost millions of dollars a day...

Twisol said:
That's not a bad thing. I just think that, if he doesn't want me to contribute in big ways, he make that clear so I can do something that will be more useful to everyone.

FWIW, and I don't mean to put words in Nick's mouth here, but I don't think he doesn't want you to contribute in big ways, he just wants to see clear justification before he invests the (probably considerable amount of) time to review and familiarize himself with large changes like this.

After all, he will be the one who has to be responsible for and otherwise answer for it in the long term, e.g. when you go to college or get a job and have less time to spend on this stuff.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #20 on Tue 07 Sep 2010 07:23 PM (UTC) [ quote ]

Message

David Haley said:
FWIW, fighting the itch to go and rewrite crufty stuff is a big learning point for all programmers, myself included. I still fight it at work sometimes. Old code is old and crufty code is crufty, but it all works, and there's plenty of new stuff that needs to get written, even if it's sometimes boring or hard.

Of course, when the old stuff doesn't work, we fix it; if it's a big pain to deal with and causes clear confusion and trouble, we consider spending time to rewrite it. Perhaps caution is more evidently appropriate in this case, though, when a software mistake can potentially cost millions of dollars a day...

But there's a certain point where there's too much effort spent fighting the cruft when you could refactor it and save everyone man-hours in the long run, which saves/makes you "imaginary dollars". I've asserted that the whole codebase is crufty, and it's hard to make changes. Of course, you've asserted that you don't change old code unless it's broken. I'm up against a pretty formidable wall, as you can see!

David Haley said:
FWIW, and I don't mean to put words in Nick's mouth here, but I don't think he doesn't want you to contribute in big ways, he just wants to see clear justification before he invests the (probably considerable amount of) time to review and familiarize himself with large changes like this.

After all, he will be the one who has to be responsible for and otherwise answer for it in the long term, e.g. when you go to college or get a job and have less time to spend on this stuff.

*sigh* Yeah, I understand. The baffling thing is that clear code is easy to maintain. There's no "I think" or "it might be" in that sentence. It flat-out is. There may be a cost in time taken to review the changes, and if Nick doesn't want to do that, that's his prerogative. But time is saved in the long run.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #21 on Tue 07 Sep 2010 07:29 PM (UTC) [ quote ]

Message

I don't think it's very realistic to say that a software project the size of MUSHclient would ever be "easy to maintain". There are many interdepedencies at a conceptual level simply because the program is complex.

Also, cleaning cruft saves time in the long run only if you actually revisit that cruft. If you have a piece of a program that is a black box and works as a black box, it can be absolutely horrid inside but it doesn't matter as long as you don't have to go look inside.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #22 on Tue 07 Sep 2010 07:33 PM (UTC) [ quote ]

Message

David Haley said:
I don't think it's very realistic to say that a software project the size of MUSHclient would ever be "easy to maintain". There are many interdepedencies at a conceptual level simply because the program is complex.

One need not look at all of the pieces to understand a single component, ideally.

David Haley said:
Also, cleaning cruft saves time in the long run only if you actually revisit that cruft. If you have a piece of a program that is a black box and works as a black box, it can be absolutely horrid inside but it doesn't matter as long as you don't have to go look inside.

In my experience - not as much as Nick's, but it's there - the problem is that there is no black box.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #23 on Tue 07 Sep 2010 09:54 PM (UTC) [ quote ]

Message

Twisol said:

The "never improve old features" thing, right. At least now I understand it.

I never said that. I am constantly improving old features, for example the ability to keep hotspots when you create a miniwindow. I added PNG file loading/saving for images. Miniwindows can now be resized.

What I am resisting is "improving" old code (stuff no-one looks at except you and me) when the improvement is simply to look nicer and maybe make it easier to make some hypothetical change in the future.

One major problem with MUSHclient is that it was written using the COM (Component Object Model) when I didn't really understand it - 15 years ago. And, that part is rubbish, really. For example,:

GetGlobalOption is part of the world document when it is irrelevant to what world is open.
Ditto for utilities like Base64Encode, XML decoding, etc.
GetSelectionStartColumn shouldn't be part of the world object - there should be a View object because you can have multiple views open. There are quite a few similar functions.
Functions that affect internal notepads should really be based on a Notepad object (not the world object).
There should be a Miniwindows object, so you can easily manipulate them. Ditto for hotspots.

The implementation is truly a mess. I acknowledge that. Fortunately it works reasonably well in its current form.

But if you are going to improve it, all this should really be fixed up, big time. But then it absolutely won't be backwards compatible, as you can imagine. Scripts would need to be rewritten, all of them.

But since the topic you started is called "Scripting engine refactoring" I looked up what refactoring means, and this is what Wikipedia says:

Wikipedia said:

Code refactoring is the process of changing a computer program's source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software.

Now when you start talking about adding the V8 Javascript engine I think you are straying from not modifying its behaviour, but lets assume that is quibbling, and that adding another script language is something we can currently easily do.

The core of my objection is that you are proposing to change the source code without modifying its external functional behavior.

http://en.wikipedia.org/wiki/Code_refactoring

Now sure, that page mentions the advantages of refactoring, and in the case of a large project (eg. for a financial organization) where changes are constantly required, this may well be a good thing.

But by the definition of refactoring, every hour that you and I spend on that is basically an hour that has no immediate benefit to anyone (because the functional behaviour is not modified). And it has to be carefully checked and tested.

Apart from mentioning Javascript you haven't suggested a major change that you want to make, that the un-refactored code makes impossible or difficult.

I've acknowledged above that the scripting interface is a mess, in many ways. But to fix it would render existing scripts (and all - or most of - the examples on this web site) unusable. Maybe you can see a benefit in that. I can't really. Not now.

Truly, my advice is, if you think the code is a mess, and the scripting interface is a mess, and miniwindows could be improved to suit the graphical API you are talking about then start again. Honestly. And I don't mean that in a rejecting way. I proposed starting again myself ...

http://www.gammon.com.au/forum/?id=8132

It could be done so much better if you start from scratch. Ask the Mudlet guys, they wrote a client recently.

Actually, speaking of them, I got an email from one of their developers who I hope won't mind being quoted here ...

Heiko Koehn said:

I think it's time to say thank you for your valued pieces of advice that you gave us.

The most important one for me clearly was your advice to stick to Lua as the only scripting language for the time being and focus on providing the best possible integration into the client instead of wasting time and resources on support for multiple other scripting languages.

At the time I wanted to integrate at least 2 or three more scripting languages from the ground up, but I thought that your 15 or so years of MUD client programming experience should be reason enough to follow your suggestion and I'm very glad I did this today, because I wouldn't have been able to finish the project otherwise.

I want you to sit and read that four or five times and digest what he said. Read the bit about "not being able to finish the project" if he tried to integrate lots of scripting languages - something you propose. Read the bit about "wasting time and resources on support for multiple other scripting languages".

I suggested a couple of years ago writing another client which used Lua only and was shouted down. Well, Mudlet did that and are thankful they did.

So what I am saying is, and what he said is, that changes to the scripting engine to support multiple languages would be wasting time and resources. I can't make it much clearer than that. I'm not saying it can't be done. Maybe someone would use it one day. Whether it is a good use of time is what is debatable.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #24 on Tue 07 Sep 2010 11:39 PM (UTC) [ quote ]

Amended on Tue 07 Sep 2010 11:42 PM (UTC) by Twisol

Message

Nick Gammon said:
Now when you start talking about adding the V8 Javascript engine I think you are straying from not modifying its behaviour

Well, I'm not adding V8. I'm refactoring the code so it will be possible to add V8 (among other things).

Nick Gammon said:
Apart from mentioning Javascript you haven't suggested a major change that you want to make, that the un-refactored code makes impossible or
difficult.

Here's two bullets from your own list of things-that-could-be-improved:

Nick Gammon said:
*Functions that affect internal notepads should really be based on a Notepad object (not the world object).

*There should be a Miniwindows object, so you can easily manipulate them. Ditto for hotspots.

Script-wise, these things are possible if we define a new interface. One that still uses Lua, yes, but one with a "thicker" layer of glue. And since it's implemented separately, plugins that use the older interface aren't affected.

Nick Gammon said:
But if you are going to improve it, all this should really be fixed up, big time. But then it absolutely won't be backwards compatible, as you can imagine. Scripts would need to be rewritten, all of them.

I've acknowledged above that the scripting interface is a mess, in many ways. But to fix it would render existing scripts (and all - or most of - the examples on this web site) unusable. Maybe you can see a benefit in that. I can't really. Not now.

That won't be necessary. The script engine interface is the lynchpin between scripts and MUSHclient. By allowing new interfaces to be defined separately from the old ones, old scripts need not be updated. It's another form of versioning.

Nick Gammon said:
Truly, my advice is, if you think the code is a mess, and the scripting interface is a mess, and miniwindows could be improved to suit the graphical API you are talking about then start again. Honestly. And I don't mean that in a rejecting way. I proposed starting again myself ...

http://www.gammon.com.au/forum/?id=8132

It could be done so much better if you start from scratch. Ask the Mudlet guys, they wrote a client recently.

I tried Mudlet, and I didn't really like it. Personal preference, I suppose.

I want to work on Aspect, but I fear that I don't have enough experience in the client field in general. MUSHclient is an already working codebase. I've mentioned this before, but since I'm learning from it, I wanted to give back to it too.

Nick Gammon said:
Actually, speaking of them, I got an email from one of their developers who I hope won't mind being quoted here ...

Heiko Koehn said:
I think it's time to say thank you for your valued pieces of advice that you gave us.

The most important one for me clearly was your advice to stick to Lua as the only scripting language for the time being and focus on providing the best possible integration into the client instead of wasting time and resources on support for multiple other scripting languages.

At the time I wanted to integrate at least 2 or three more scripting languages from the ground up, but I thought that your 15 or so years of MUD client programming experience should be reason enough to follow your suggestion and I'm very glad I did this today, because I wouldn't have been able to finish the project otherwise.

No, see, I agree. One language makes much more sense. I'm just working with what we have here, and trying to make it better. Expanding the interface support will allow us to craft a newer Lua interface without breaking older scripts, as I described earlier. (Among other things. I don't expect you to include a V8 interface, but I'd write it into my version of the source just because that's awesome.)

Nick Gammon said:
I suggested a couple of years ago writing another client which used Lua only and was shouted down. Well, Mudlet did that and are thankful they did.

Hence why I'm working with what we've got, rather than angering your valued user base. :)

Nick Gammon said:
So what I am saying is, and what he said is, that changes to the scripting engine to support multiple languages would be wasting time and resources. I can't make it much clearer than that. I'm not saying it can't be done. Maybe someone would use it one day. Whether it is a good use of time is what is debatable.

Fact is, it already supports multiple languages. It's also very rigid, and there are a lot of things that a newer Lua interface can offer that plugin authors would love.

Yes, I'm settling on an updated Lua interface as my "end goal", following these refactorings. I think it's a worthy goal, don't you?

As always, thanks for your honest feedback, Nick.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #25 on Wed 08 Sep 2010 07:11 AM (UTC) [ quote ]

Message

Quote:
Script-wise, these things are possible if we define a new interface. One that still uses Lua, yes, but one with a "thicker" layer of glue. And since it's implemented separately, plugins that use the older interface aren't affected.

Having a thicker layer of glue for Lua does not require a full rewrite of the scripting engine to add support for any abstract scripting language. In fact, it seems that it would be far more expedient to not do that, and instead introduce tight coupling for Lua. You've just said yourself that having one language is fine and even better; why are we so concerned, then, with all these other hypothetical languages?

If the task at hand is "make more stuff possible for Lua", that gives us a very different direction than the (hypothetical) task of "add an abstract interface for integration with any scripting language".

Quote:
I want to work on Aspect, but I fear that I don't have enough experience in the client field in general.

This is not meant to offend in any way whatsoever, but to be an earnest question. If you don't feel that you have the experience to make it work, why do you feel that you know that all these proposed changes will actually be beneficial or even possible once all necessary interdependencies are sorted out?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #26 on Wed 08 Sep 2010 07:18 AM (UTC) [ quote ]

Amended on Wed 08 Sep 2010 07:19 AM (UTC) by Twisol

Message

David Haley said:
Having a thicker layer of glue for Lua does not require a full rewrite of the scripting engine to add support for any abstract scripting language. In fact, it seems that it would be far more expedient to not do that, and instead introduce tight coupling for Lua. You've just said yourself that having one language is fine and even better; why are we so concerned, then, with all these other hypothetical languages?

If the task at hand is "make more stuff possible for Lua", that gives us a very different direction than the (hypothetical) task of "add an abstract interface for integration with any scripting language".

With the current state of affairs, changing the Lua glue would break backwards compatibility with older scripts. Neither Nick or I are willing to sacrifice that. And I am emphatically not going to add another short-circuit behavior for an extended Lua interface like what was done originally for Lua. Heavier glue means more complex glue. It would be a veritable nightmare, not just to maintain, but indeed to write.

David Haley said:

Quote:
I want to work on Aspect, but I fear that I don't have enough experience in the client field in general.

Things already work in MUSHclient. I can study it and understand it. With Aspect, I'm working from a blank slate. I'm sure I could do it in time, but I'd like to understand how a functional (and popular) client works instead, to save me the trouble. Sort of an inversion of the NIH syndrome. And once I understand how the pieces of MUSHclient work, I'm in a position to give back to the client.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #27 on Wed 08 Sep 2010 03:15 PM (UTC) [ quote ]

Message

Quote:
With the current state of affairs, changing the Lua glue would break backwards compatibility with older scripts.

Why? If you're only adding new ways of talking to Lua, any old script will work.

Quote:
And I am emphatically not going to add another short-circuit behavior for an extended Lua interface like what was done originally for Lua. Heavier glue means more complex glue. It would be a veritable nightmare, not just to maintain, but indeed to write.

My experience doesn't agree with this, but eh. A magic scripting interface won't solve all of your problems; you will need the "heavier glue" one way or the other. In fact, your proposal makes it all the more complicated, because it has to be language-agnostic until the last minute...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Reply #28 on Wed 08 Sep 2010 04:42 PM (UTC) [ quote ]

Amended on Wed 08 Sep 2010 04:46 PM (UTC) by Twisol

Message

David Haley said:
Why? If you're only adding new ways of talking to Lua, any old script will work.

Meh. If we're going to improve the Lua interface, I'd like to do it right the whole way down. Much more object-based, like Nick suggested with Miniwindow and Hotspot and Notepad objects.

David Haley said:
My experience doesn't agree with this, but eh. A magic scripting interface won't solve all of your problems; you will need the "heavier glue" one way or the other. In fact, your proposal makes it all the more complicated, because it has to be language-agnostic until the last minute...

My plan is to define a method in IScriptEngine for each MUSHclient-to-script call (i.e. alias callback, trigger callback, each plugin callback). It's language-agnostic right until the last minute, because each script engine decides how to handle that event's particular arguments.

I invite you to glance over how it's currently done, by the way. It's in the scripting/ folder, under scripting.h, scriptengine.cpp (WSH interface) and lua_scripting.cpp (Lua interface).

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #29 on Wed 08 Sep 2010 04:54 PM (UTC) [ quote ]

Message

Quote:
Meh. If we're going to improve the Lua interface, I'd like to do it right the whole way down. Much more object-based, like Nick suggested with Miniwindow and Hotspot and Notepad objects.

This isn't answering the question. What prevents you from having a full object interface without affecting the existing interface?

You could even create some kind of Lua object that had an entry per supported plugin callback, with the difference that the parameters would be richer userdata rather than strings etc. So it wouldn't even look that different as far as script authors are concerned.

I get the impression that you're going straight to the most complex solution but without even really considering the simpler solutions or what the practical tasks and goals are.

Quote:
I invite you to glance over how it's currently done, by the way. It's in the scripting/ folder, under scripting.h, scriptengine.cpp (WSH interface) and lua_scripting.cpp (Lua interface).

I'll take a look sometime soon, then.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

7,958 views.

This is page 2, subject is 4 pages long: 1 2 3 4

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )