I am trying to integrate javascript for back-end support of cloud apps. I noticed the fcl-js package. Does anyone have an idea when we can expect to have a component suite much like the PascalScript?

Thanks,

Andrew Brunner wrote

I am trying to integrate javascript for back-end support of cloud apps. I noticed the fcl-js package. Does anyone have an idea when we can expect to have a component suite much like the PascalScript?

If you want to integrate JS in a pascal app, you can use libsee in fpc apps. There is alse a native pascal script engine somewhere, as well as delphi-javascript on google code.

Michael.

If you're back end is on a windows machine this is probably the easiest solution:

http://www.codebot.org/delphi/?doc=9573

Otherwise, you might want to consider chromium embeded framework and just reusing the exposed Javascript engine. here is a link for that:

https://code.google.com/p/dcef3/

Consider https://github.com/BeRo1985/besen, https://code.google.com/p/fpcjs/ and the SynSM Spidermonkey library from the Synopse.info project. I got Besen and fpcjs to run, but Besen gave me on error on one script and fpcjs is rather dated. The SynSM project is probably the best choice, but you will probably have to help the developers test it fully with Free Pascal

I have Besen installed and I am in the process of evaluating it.  It
does not handle nested classes.
I need a JIT compiler that provide access to heavily nested class
information.  This PostInfo is a simple database module that I would
want Script to have access to.
---------------------------
// sample interface with no implemenation
---------------------------
Type
   PostInfo= class
   type
     IDs= class
     const
       ID                     = 0;
       InsertID               = 1;
       DomainID               = 2;
       IP                     = 3;
       Created                = 4;
       Form                   = 5;
       Data                   = 6;
     end;
     Keys=class
     const
       ID                     = 'ITMID';
       InsertID               = 'ITMIID';
       DomainID               = 'ITMDID';
       IP                     = 'ITMIP';
       Created                = 'IDTC';
       Form                   = 'IFRM';
       Data                   = 'IDAT';
     end;
     XML=class
     type
       Stanzas=class
       const
         Info               = 'pstinf';
       type
         Fields=class
         const
           ID               = 'id';
           Created          = 'ctd';
           IP               = 'ip';
           Form             = 'frm';
           Data             = 'dta';
         end;
       end;
     end;
     Email=class
     const
       Address              = 'au-eml-addr';
       NameSpace            = 'au-eml-ns';
       Subject              = 'au-eml-sbj';
       Body                 = 'au-eml-bdy';
     end;
     const
       TableP: PDatabaseTable = nil;
       MonitorP: PDBMSMonitorItem = nil;
       Startup: TDBTableIni = (
         AutoCreate: True;
         AutoCommit                   : True;
         Group: 'Domains/Storage';
         Name: 'Post Info';
         Value: 'scs_pstinfo';
         Hint: 'Table for accepting domain level form data from the web.';
         PrimaryField: Keys.ID;
         );
       Fields: array [0..6] of TDatabaseField = (
         (PropertyID: IDs.ID; DataType: dftQWord; AutoCreate: True;
Verified: False; Precision: 0; Flags: cfNotNull or cfPrimaryKey or
cfIdentity; Name: Keys.ID; ),
         (PropertyID: IDs.InsertID; DataType: dftQWord; AutoCreate:
True; Verified: False; Precision: 0; Flags: cfNone; Name: Keys.InsertID; ),
         (PropertyID: IDs.DomainID; DataType: dftQWord; AutoCreate:
True; Verified: False; Precision: 0; Flags: cfNone; Name: Keys.DomainID; ),
         (PropertyID: IDs.IP; DataType: dftQWord; AutoCreate: True;
Verified: False; Precision: 0; Flags: cfNone; Name: Keys.IP; ),
         (PropertyID: IDs.Created; DataType: dftDouble; AutoCreate:
True; Verified: False; Precision: 0; Flags: cfNone; Name: Keys.Created; ),
         (PropertyID: IDs.Form; DataType: dftShortString; AutoCreate:
True; Verified: False; Precision: 255; Flags: cfNone; Name: Keys.Form; ),
         (PropertyID: IDs.Data; DataType: dftMemo; AutoCreate: True;
Verified: False; Precision: 0; Flags: cfNone; Name: Keys.Data; )
       );
       class function  Post(Var Module:TDBMSModule; Var Task:TDBMSTask;
DomainID,IP:QWord; Form:TVarString; Data:TVarString): Boolean;
   end;

--------------------------

I need a JITC to provide access to native FPC code that looks like this on the compiled side, but would be implemented like so in the cloud.

Before BESEN.Execute, would need to have access to FPC runtime variables like Module,Task,IP
if (PostInfo.Post(Module,Task,DomainID,IP,Form,Data)==false){

   Log('FAILED to write');

} else {

   Log ('WooHoo');

};

Nested classes are a modern way to organize complex API and code into very easy to read code. Most of the modules I have are extremely nested, the one I chose here is easy and strait forward.

I see PascalScript is part of the Lazarus project now. I have not been able to get nested classes to work there either. If I am to get my code accessible, I will need someone with knowledge in extending BESEN or PascalScript or both. I would be ideal to offer developers a choice of which scripting language they want to write back-end code.

But if I am to provide developers with instant API to do complex code that is relevant to computing needs of today, I will need access to nested objects in either of these JITCs.

Anyone familiar with BESEN or PascalScript that could shed some light?

[]

And already utterly unreadable for me...
IMHO goes to show that this is a very personal matter :-)

Can you explain why nested classes cannot be handled in e.g. besen ? They are no different from normal classes except in their name, a fact that could probably be handled through some stringreplace('.','_') or so.

Michael.

I don't think PascalScript should have real problems with using them then. The only problem is that the importer doesn't support them.

I suspected as much, but I am not an expert on both engines...

Michael.

Michael Van Canneyt wrote

And already utterly unreadable for me... IMHO goes to show that this is a very personal matter :-)

Units that include hierarchy via class types are a supplement for namespaces in languages such as c#. Since Namespaces are not *yet* available in FPC we have to use classes.

The dotted notation in libraries that use the organized unit makes for easy code readability as well as having global variables available within the namespace. So things like naming conventions become standard.

I have attached a 3.4kb example unit that is the back-end db module.

CMS.XML "namespace" holds all my XML related types,vars,consts,etc.

Units that use this module declare things like

var PP:dbmCMS.CMS.TPagePoint;

I realize the similarities in having a unit results in the same code as above however, the real benefit comes when the database modules become more complex.

The single most important feature I absolutely love is having *.TItem and *.TItems where * is a hierarchy of nested classes (purposely namespace). My most complex database module dbmSocial. There I have Files.TItem/TItems and Folder.TItem/TItems.

I hope the attached unit brings some clarity to my motivation and need for having organized units with namespaces (currently as nested classes).

Namespaces are available as dotted units ?

Michael.

namespaces in languages such as c#. Since Namespaces are not *yet* available in FPC we have to use classes.

Namespaces are available as dotted units ?

But 3.0.0 is not yet released and some people rely on release versions...

Regards,
Sven

Michael Van Canneyt wrote

Namespaces are available as dotted units ?

Namespace as dotted units? I use 3.1.1 compiled here so there is no problem. FPC since as far as I recall (svn) has had support for naming units with multiple dots. I've had tons of units with includes and I dot them for quick functionality review in directory listings.

Hmmm... The only problem is it seems pretty cheap. I love the advanced look of my complex units. I would have to break out each unit and maintain a bunch of separate units. I could see how this was a delphi-like feature but its not done in a modern fashion.

Just wondering how much work it's going to take to have nested class support.

So it's a matter of personal preference, not functionality. Any serious discussion stops there, of course:
De gustibus non disputandum est.

I would have to break out each unit and maintain a bunch of separate units. I could see how this was a delphi-like feature but its not done in a modern fashion.

To be sure, it was introduced to be delphi compatible. Whether namespaces are 'modern','advanced' or not is a matter of debate. In the end (at the assembler level) it's all a flat namespace anyway.

At any rate, your choice of the word 'fashion' was probably spot-on: fashion changes at least twice a year :)

Michael.

Michael Van Canneyt wrote

To be sure, it was introduced to be delphi compatible. Whether namespaces are 'modern','advanced' or not is a matter of debate. In the end (at the assembler level) it's all a flat namespace anyway.

But namespaces are functional in Delphi - not just cosmetic. So are you saying that FPC doesn't have the same functional ability as Delphi when it comes to namespaces?

The following is how somebody explained Delphi namespaces to me:

In stead of having directories like this with the same unit names and having to use IFDEF's and play with unit paths...

/GUI/VLC/tiMediators.pas
/GUI/VLC/tiListMediators.pas
/GUI/LCL/tiMediators.pas
/GUI/LCL/tiListMediators.pas
/GUI/FMX/tiMediators.pas
/GUI/FMX/tiListMediators.pas

...instead you can flatten the directory hierarchy to simply a single GUI directory as follows:

/GUI/VLC.tiMediators.pas
/GUI/VLC.tiListMediators.pas
/GUI/LCL.tiMediators.pas
/GUI/LCL.tiListMediators.pas
/GUI/FMX.tiMediators.pas
/GUI/FMX.tiListMediators.pas

That way we don't need $IFDEFs or special Unit Search Paths, just specify "FMX" or "VCL or "LCL" in the Project Unit Scope names list.

You then simply refer to those units in your uses clause by using:

  uses
    tiMediator, tiListMediator;

The compiler will then know which unit to use because of the scope you specified in the project.

I take it FPC doesn't support this then?

Regards,
- Graeme -

you just change one option -Fu/GUI/LCL to 2: -Fu/GUI -NLCL I don't see much added value in that.

Additionally I like my files in separate directories.

It's all a matter of preference.

As for ifdefs:
The units MUST have the same interface or else the IFDEFS pop up anyway. So nothing is gained with namespaces (in this regard). We do the above since 20 years in the RTL. The LCL has macros for it.

Don't get me wrong, I have nothing against namespaces. I just don't think they are the "sliced bread of IT" as some do. Their usefulness in pascal is IMHO hugely overrated.

To my knowledge, it does ?

Michael.

Michael Van Canneyt wrote

It's all a matter of preference.

Fair enough.

> I take it FPC doesn't support this then? To my knowledge, it does ?

So what compiler parameter option do you use to specify the namespace scope list for your project? As far as I can see there isn't such an option. And I'm not talking about compiler defines (-dXXX)

Regards,
- Graeme -

I don't think the command-line option already exists, but the dotted unit names are treated as namespaces. I remember some discussions about it with Paul Ishenin.

Michael.

Michael Van Canneyt wrote

I don't think the command-line option already exists, but the dotted unit names are treated as namespaces. I remember some discussions about it with Paul Ishenin.

So that answers my original question, that FPC still doesn't support namespace functionality like Delphi. :-) You can't specify the namespace scope, so the compiler cannot know which units to use if there are multiple units with the same partial qualified unit names. So currently it is just a cosmetic "thing" (fancy unit names) in FPC.

Just for reference, here is the Namespace Prefixes option in Delphi's project options. See the screenshot.

https://sergworks.wordpress.com/2011/08/09/dotted-unit-names-in-delphi/

Regards,
- Graeme -

Michael Van Canneyt wrote

you just change one option -Fu/GUI/LCL to 2: -Fu/GUI -NLCL I don't see much added value in that.

Other possibly (more useful) usage would be reducing the generic unit name clashes. eg: How common is the unit name constants.pas? Very common. So when using various libraries that all could contain a unit named constants.pas, using namespaces means we can easily get around the unit name clash issue.

ps:
I've never used namespaces in any of my projects, but I sure can see a use for it. Beyond the "flatten directory hierarchy" example I mentioned earlier.

ps #2:
Unit namespace clashing is exactly why fpGUI uses the fpg_* unit name format. Because my first attempt of FP* and fpg* clashed with units included with FPC.

Regards,
- Graeme -

I think you'll find it's slightly more complicated than that, there is more involved than just fancy unit names.

The namespace directive/command-line option is just the cherry on top :)

Michael.

In our previous episode, Graeme Geldenhuys said:

Something like that yes, if various frameworks use similar unitnames.

Not entirely, since you can afaik use the whole unit names qualified ? So the "real" core module name is now the qualified one, even if you can omit the prefix ^H^H^H^H namespace under certain circumstances.

I understand that, but in the context of the example, the tiOPF project has different implementations of the same functionality for different GUI toolkits. So in that case the developer would use the partial namespace unit name (tiMediator or tiListMediator) in the uses clause, and the compiler will figure out which fully quality unit you mean, by looking at the Namespace Scope List.

In my other example with using very generic unit names (eg: constants.pas), then you would opt to use the fully qualified unit name in the uses clause to tell the compiler which unit you are referring too.

So those are two very different situations and uses of the namespace feature. Like I said, I've never used namespaces personally, but I'm sure more usage examples exist. I think it is quite a useful feature, and should not only be considered "cosmetic unit names".

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

True, but keep in mind if more component vendors have that attitude, the number of scopes that must be in the list rises again, with the risk of conflicts.

It is mainly to fix these issues in Embarcadero's OWN system.

In my other example with using very generic unit names (eg: constants.pas), then you would opt to use the fully qualified unit name in the uses clause to tell the compiler which unit you are referring too.

True. Like Lazarus and FV both have "dialogs".

So those are two very different situations and uses of the namespace feature.

No. Since if you prefix with namespace you usually do that because you have some scope case (like importing legacy projects). Otherwise you would immediately call it lcldialogs instead of lcl.dialogs.

Like I said, I've never used namespaces personally, but I'm sure more usage examples exist.

Anything that exists can be abused :_)

I think it is quite a useful feature, and should not only be considered "cosmetic unit names".

The transition is annoying. If we would rename e.g. LCL now, it would not work with 2.6.4 anymore, and working around that (by leaving all code the same and adding a scope name) would require careful upgrading of old projects.

In Delphi mixing XE2 and later and before is annoying for that reason too. (and I know, since we have XE and XE3 in our company ;-)