Or a roadmap of sorts. The basic idea is to maintain forward compatibility for the “external” aspects: the language and the components. At the same time, the internals of DWS will be subject to evolution, incremental Darwinian evolution, rather than a straight break into some next-gen architecture.
The main goals:
- Strong typing: this is a long term goal of dropping “Eval : Variant” methods, and ultimately, the reliance on Variant. Variants will stay in the scripting language though, but may become optional (see below). Changes will be incremental, with new methods and classes popping into existence, some as temporary glue, and other bits of code will fade away. What this means is that you shouldn’t rely on the internals classes, their methods, or even their still being there down the road.
- Expression tree: this is an architectural goal of keeping the expression tree “understandable” and maintainable. Even though specialized classes may come to abound, higher level classes will be maintained to keep the expression tree easy to understand and maintain. This is to allow using the expression tree as a specialized DOM, facilitate debugging, refactoring, static analysis, etc.
- Custom primitive types: allow optional primitive types to be plugged into the compiler, I’m thinking primarily of Variant, date-time, vectors and matrices at this time. From a language point of view, this could also mean optionally allowing operator overloading.
- Generics/Templates: provide some mechanisms for genericity, at least on the Delphi side, so that you can f.i. have a “TList<T>” in the scripts, even if you may not be able to design a generic containers in script.
- Local JITter: introduce a framework to simplify JITting portions of a script. The initial aim would be for math computations involving floats, vectors & matrices into SSE instructions. Complete JITting isn’t on the radar at this point, and probably shouldn’t be. This is unlikely to happen until a 64bit Delphi compiler is out.
If you want to help on the DWS compiler & runtime side, at this point the most needed things are unit tests. Can’t have too much of them :).
Library, tools and utilities front:
DWS2 came with a rather vast set of companion libraries, tools and utilities, covering many things from HTML web page generation to auto-completion support functions. At this point I will not focus on those, but on the core aspects mentioned above.
There are however a few RTL-like sets of libraries still to be released, TStringList, TStringBuilder, TXxxxList, file access, etc. all these providing extra optional functionality for the scripts.
If some of you want to help on that front, or need some of the treasures from the old DWS2 chest, they can go ahead and bring the old code up to Unicode Delphi, things should be compatible for the most part on the DWS side apart from a few name changes.
Documentation:
A natural choice would be the google code wiki facility, but it’s very primitive to say the least. Another possibility is wikia, but I’ve no idea how easy it would be to export/backup a wikia wiki at this point, should wikia go the way of the Dodo. Another option would be a no-database, xcopy-installable, portable wiki like PmWiki. I’m still looking around, if you’ve suggestions.
AFAIR DWS requires those Wrapper-Functions for every Delphi-Function called in a Script. In RemObjects Pascalscript are those Wrappers not required, only a registration of the Methodpointer of the Delphi-Function.
Is it possible to eliminate those Wrappers too in your next-gen DWS?
Hi!
Oh nice. You’re reviving DWS. 😀
I just wanted to say that I’m using (the old) DWS successfully with Free Pascal on a Linux 64-bit webserver (and also on Win32 and Linux x86 test systems). I needed to modify it a bit so that it compiles though.
I’d love if you’d try to achieve FPC compatibility with your revive or I might even help you to do this if you can’t focus on it by yourself.
Regards,
Sven
It is possible, and I’m planning to have a look at it with Delphi 2010+ extended RTTI.
However IME, apart from very simple functions, wrappers are often desirable to add user-friendly parameter checking and error clarification. Another issue is that whatever you expose in a script becomes “forever”, because if useful, you’ll have lots of scripts depending on the exposed classes and parameters, scripts you typically don’t have control of. Wrapping allows to explicitly separate what the script users see from what you have internally in Delphi, and allow both sides to evolve without hindering each other.
So in practice here, we never expose “raw” functions or business classes (apart from initial mistakes…), as exposing raw stuff repeatedly turned into “save a penny, lose a dollar” situations down the road…
Nice Sven! I’ve only had a quick look at FreePascal (via Lazarus), but apparently it didn’t have support for records-with-methods, which are now getting used in a few areas to replace objects with records (to cut down on memory usage). Maybe that was added since, in which case things could be simpler.
records-with-methods are not yet supported, because Florian does not yet want to open that “can of worms” that are implied by that (don’t ask me… as a compiler dev he knows more than we do ^^). But he also mentioned in one of the generics related bug reports that they might need to implement them sooner or later.
But I might nevertheless take a look at your new code and will see what can be done. ^^
Btw: is there really that much difference in records vs. objects? Or do you mean classes?
Regards,
Sven
@Eric
I’ve a working TdwsHTMLFilter. I’ve just written some unit tests for it.
I haven’t access to the code repository.
Contact me please: http://www.danieleteti.it/?page_id=241
The old “object” type? Should work, before getting the code to D2009, that’s what I was using IIRC.
Well… if you’d use “object” instead of “records-with-methods” you’d also achieve Pre-Delphi-2006 compatibility (I believe that was when they were added).
But I don’t know
1) how good the “object” support is in Delphi (in FPC it’s good and is still improved if someone sees a need for it)
2) whether “records-with-methods” give you something that “objects” don’t (besides the different usage with “new” and “dispose”)
Another possibility would be to ifdef the code, so that Delphi-2006-Newer uses records-with-methods and Pre-Delphi-2006 and FPC code use something different.
In the end it’s your decision as you’re the current maintainer.
Regards,
Sven
AFAIK “object” is obsolescent and somewhat deprecated. I’m using the records with methods as decorated static records however, to eliminate dynamic allocation and have things like lists be “embedded” into their owner objects.
The other issue is Unicode, which kinda makes supporting pre-Delphi 2009 more complicated. I don’t know how FreePascal fares in that regard.
As for support, FreePascal would be a plus, but pre-Delphi 2009 isn’t really that relevant anymore.
The object type was deprecated even in Delphi 1.0 – it was a hang-over from TurboPascal and never officially part of the Delphi era Pascal vocabulary.
However… they worked.
Yes there were some problems but most if not all of those were easily recognised and avoided (and iirc still affect “records with methods”, or perhaps the compiler prevents you from getting into a mess with those in a way that it didn’t with object types, but either way…)
“Records with methods” was a bogus direction to go in… they should have brought object types back into the fold (they are, after all, functionally and semantically very similar to “records with methods”, but avoid overloading the concept of a “record” itself).
And records with methods lack a key ability that object types had – inheritance.
This makes perfect sense – records are not classes, they are not OO as such. Adding inheritance to records with methods just makes records even more confusing.
Much clearer imho to have maintained records as… records, and address the problems with object types.
Just imho.
@Eric:
There is a branch of FPC where they are trying to implement something similar to Delphi’s Unicode (but a bit more “clean”). But it’s still work in progress.
FPC itself still uses AnsiString while Lazarus uses UTF8 encoded strings (instead of WideString).
If you’d define a ifdef’d string type (see below) and string routines that don’t rely on the size of one char you could at least avoid this compatibility problem. The records are a different matter ^^
Example:
{$ifdef fpc}
DWSString = AnsiString;
{$else}
DWSString = WideString;
{$endif}
// you could use “String” in both cases, but this way things are more clear to the viewer ^^
@Jolyon:
Yes, that would have been the better way if records would have stayed simple data containers… they already had a stack based type that supported constant initialization (or is this a FPC only feature?) and methods… but no, they had to torture the pure records. -.-
But despite “object” being somewhat deprecated in Delphi (not in FPC) they are still there and still useable. And I don’t think that Embarcadero will drop them, because (besides the Unicode-breakage) they (or better: the Delphi devs) love to praise around with their backwards-compatibility.
@Eric (again ^^):
What do you think about ifdef’ing the code, so that the older and FPC compatible code uses “object” and the newer one uses “record”? This can be dropped later when the FPC devs decide to implement records-with-methods (I believe that they will have to do that… at least to stay Delphi compatible with Delphi 2006 and beyond).
Regards,
Sven
@Sven B.
After a quick look, I don’t think there should be much trouble with Unicode in the dws core itself, the only sensitive part is the tokenizer, and it should be char-size insensitive (except for # charcode parsing).
Is there a DUnit equivalent in Lazarus? Is there a particular version to use or avoid of Lazarus? I would like to quickly see how many issues there really are when attempting to compile & run with FreePascal.
Yes, there is a DUnit equivalent distributed with FPC (it’s called fpcunit, you can find the units in the FPC directory in “packages/fcl-fpcunit” (the search paths are included by default)). It is DUnit v1.x if that’s of interest (one of the users of FPC has ported DUnit v2.x as well, but I don’t know whether he published his port).
Currently I’m using Lazarus 0.9.28.2 on Windows and so far that version is rather stable (some bugs are in there, but they are fixed in either 0.9.28.3 or the current trunk version 0.9.29). The stability of the trunk version depends on whether someone dared to commit a new feature. 😛
I’d suggest to use 0.9.28.2 (still uses FPC 2.2.4) or 0.9.28.3 (uses FPC 2.4.0 and can be found here ftp://ftp.hu.freepascal.org/pub/lazarus/snapshots/ ).
The next stable version of Lazarus is “sheduled” to be released after the next version of FPC, 2.4.2 is released (it’s currently in RC phase, so that still might take some time).
I hope this information helps you.
Regards,
Sven
Hi i dont kknow where to find help on this. Im new one
Can we with dws access objects on delphi ???
What i mean is , im trying to acess a delphi form and receive events from it and execute the refered script.
Ex : form OnClick event and execute then script procedure myform(Sender : TObject); begin beep; end;
Can you help me on this ???