Looking for JavaScript component on FPC

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Looking for JavaScript component on FPC

Andrew Brunner-2
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

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, music, and more.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Tue, 31 Mar 2015, 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Anthony Walter-3
In reply to this post by Andrew Brunner-2
If you're back end is on a windows machine this is probably the easiest solution:


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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

vfclists .
In reply to this post by Michael Van Canneyt


On 31 March 2015 at 22:06, Michael Van Canneyt <[hidden email]> wrote:


On Tue, 31 Mar 2015, 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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

--
Frank Church

=======================
http://devblog.brahmancreations.com

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Andrew Brunner-2
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?

--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, music, and more.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Wed, 1 Apr 2015, Andrew Brunner wrote:

> 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.
[]

>  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.

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

>
> 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?

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Carlo Kok-2



>>
>> 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?
>
> 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.
>

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


--
Carlo Kok
RemObjects Software
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Thu, 2 Apr 2015, Carlo Kok wrote:

>
>
>
>>>
>>> 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?
>>
>> 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.
>>
>
> 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Andrew Brunner-2
In reply to this post by Michael Van Canneyt
On 4/2/2015 2:24 AM, 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).



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

dbmCMS.pas (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Thu, 2 Apr 2015, Andrew Brunner wrote:

> On 4/2/2015 2:24 AM, 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.

Namespaces are available as dotted units ?

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Sven Barth-2

Am 02.04.2015 18:46 schrieb "Michael Van Canneyt" <[hidden email]>:
>
>
>
> On Thu, 2 Apr 2015, Andrew Brunner wrote:
>
>> On 4/2/2015 2:24 AM, 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.
>
>
> Namespaces are available as dotted units ?

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

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Andrew Brunner-2
In reply to this post by Michael Van Canneyt
On 4/2/2015 11:46 AM, 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.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Thu, 2 Apr 2015, Andrew Brunner wrote:

> On 4/2/2015 11:46 AM, 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.

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Graeme Geldenhuys-6
On 2015-04-03 08:09, 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 -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Fri, 3 Apr 2015, Graeme Geldenhuys wrote:

> On 2015-04-03 08:09, 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 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.

> 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?

To my knowledge, it does ?

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Graeme Geldenhuys-6
On 2015-04-03 10:39, 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 -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt


On Fri, 3 Apr 2015, Graeme Geldenhuys wrote:

> On 2015-04-03 10:39, 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)

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Graeme Geldenhuys-6
On 2015-04-03 11:52, 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 -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Graeme Geldenhuys-6
In reply to this post by Michael Van Canneyt
On 2015-04-03 10:39, 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 -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Looking for JavaScript component on FPC

Michael Van Canneyt
In reply to this post by Graeme Geldenhuys-6


On Fri, 3 Apr 2015, Graeme Geldenhuys wrote:

> On 2015-04-03 11:52, 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.

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12