binarycloud-dev

[binarycloud-dev] Another kneejerk suggestion for import()

[Justin F. <je...@ey...>]

Alex:

I feel like I am bombarding you today...

What about this syntax to ship enough information to
import() in order to distinguish "package" from "file":

	import('a_file_name')

	for importing a "true file object", and

	import('package_name:object')

	for importing an "object" from a "package"????

See, this would suit me.  Maybe not everybody.  I NEVER
USE A COLON in file names.  Somebody might.  But, I
would argue that in the great corpus of UNIX conventions,
using dots in file names probably prevails over using
colons in file names by at least 100 to 1.  Hell, I
don't really know that, but I bet you agree...

Boff.  I am stopping now with this struggling with
this problem for the time being and go make my modules
work on the new r2, and wait for you to get out of
bed and respond.  Maybe you have already fixed the
problem in your dreams out there in PST.

_jef

-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

Hi Justin,

> What about this syntax to ship enough information to
> import() in order to distinguish "package" from "file":
> import('a_file_name')
> for importing a "true file object", and
> import('package_name:object')
> for importing an "object" from a "package"????

Another one could be:

Leave import for packages as is:
import('binarycloud.core');
import('binarycloud.core.Init);
etc.

add resource handler for true files:

import('file:a_file_name');


.andi

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[Justin F. <je...@ey...>]

Andreas:

Hey, I can live with that.  It makes the distinction
that I was wanting, would have sufficient information
in it for import() to allow me to have "dots" in
my file names, I think.

And, of course, you are correct about the economy
of a single call to "load a package" without
have to worry about that package's inventory/names
changing from underneath you.  Yes, I like that.

Right now, I am a bit confused, because I don't know
what the intentions of Alex are, and if this would
fit in the grand schems.  It seems to me, however,
that your idea is good, and aligns itself with what
Alex is thinking.  I also like your syntax better
than what I suggested as a kneejerk, that is, your
syntax only requires one argument to import().
That is better.

It still won't allow me, I think, to name my
layout files *.layout, my masters *.master, and
so forth.  Somehow, I still would like to retain
that possibility.  I also still feel that within
the system, for the only example that Alex/Odysseas
gave where *.php is "necessary", like using
the filter xml2php, there could be a solution.
That solution would be to put a "wrapping environment"
around those operations by, say, appending ".php"
before the operation, and stripping ".php" after
the operation.

Sure, this adds some overhead, but it is trivial.
Right now, you cannot even have your files named
*.PHP, or *.phtml, which is functionally identical
to *.php, but gives my "need" a bit more force.
Lordy, I hate the idea that, right now, I cannot
name my files

	*.layout

or as a partial compromise

	*.layout.php

because it throws away the ability of easily
constructing find(1) scripts or globbed
arguments to any argument to any of the
standard UNIX/Linux utilities needed for
easy administration.  If I had to do things
like name my files:

	file01Layout.php
	file07Master.php
	file09Module.php

and the go sed(1) everywhere in my scripts,
I would get very tired and irascable.  Er,
I am already tired and irascable... 

Again, I like your suggestion.

_jef

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

Andreas Aderhold wrote:
> 
> Hi Justin,
> 
> > What about this syntax to ship enough information to
> > import() in order to distinguish "package" from "file":
> > import('a_file_name')
> > for importing a "true file object", and
> > import('package_name:object')
> > for importing an "object" from a "package"????
> 
> Another one could be:
> 
> Leave import for packages as is:
> import('binarycloud.core');
> import('binarycloud.core.Init);
> etc.
> 
> add resource handler for true files:
> 
> import('file:a_file_name');
> 
> .andi
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[alex b. <en...@tu...>]

> Hey, I can live with that.  It makes the distinction
> that I was wanting, would have sufficient information
> in it for import() to allow me to have "dots" in
> my file names, I think.

That would only be true if we change the delimiter. I'd like to have a
conversation with Odysseas about this one.

> And, of course, you are correct about the economy
> of a single call to "load a package" without
> have to worry about that package's inventory/names
> changing from underneath you.  Yes, I like that.
>
> Right now, I am a bit confused, because I don't know
> what the intentions of Alex are, and if this would
> fit in the grand schems.  It seems to me, however,
> that your idea is good, and aligns itself with what
> Alex is thinking.  I also like your syntax better
> than what I suggested as a kneejerk, that is, your
> syntax only requires one argument to import().
> That is better.

If you are talking about Andreas file: resource handler, I don't see the
point.

Why not just use include_once in that case?

That is a separate issue from the import package delimiter, which would
still prevent you from doing an import on My.File.With.Lots.Of.Dots.php

> It still won't allow me, I think, to name my
> layout files *.layout, my masters *.master, and
> so forth.  Somehow, I still would like to retain
> that possibility.  I also still feel that within
> the system, for the only example that Alex/Odysseas
> gave where *.php is "necessary", like using
> the filter xml2php, there could be a solution.

That is only for the moment.

Soon, we will be filtering _all_ php code for language strings, maybe
comments, and I'm sure other stuff I haven't thought of yet - and that will
require us to have a mechanism for distinguishing php from xml and html fro
php, etc.

From a cursory discussion I had with odysseas, that would be possible
through a make-make system, but we're getting into esoterica at that point
:)

> That solution would be to put a "wrapping environment"
> around those operations by, say, appending ".php"
> before the operation, and stripping ".php" after
> the operation.

Can you qualify this a little more? What do you mean?

> Sure, this adds some overhead, but it is trivial.
> Right now, you cannot even have your files named
> *.PHP, or *.phtml, which is functionally identical
> to *.php, but gives my "need" a bit more force.
> Lordy, I hate the idea that, right now, I cannot
> name my files
>
> *.layout
>
> or as a partial compromise
>
> *.layout.php
>
> because it throws away the ability of easily
> constructing find(1) scripts or globbed
> arguments to any argument to any of the
> standard UNIX/Linux utilities needed for
> easy administration.  If I had to do things
> like name my files:
>
> file01Layout.php
> file07Master.php
> file09Module.php

How do you suggest we handle the fact that make must have implicit knowedge
about file extensions at build-time?

I'd like to hear what you think before responding.

> and the go sed(1) everywhere in my scripts,
> I would get very tired and irascable.  Er,
> I am already tired and irascable...
>
> Again, I like your suggestion.

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

> Hey, I can live with that.  It makes the distinction
> that I was wanting, would have sufficient information
> in it for import() to allow me to have "dots" in
> my file names, I think.

Yepp, but it alianates import(). On the other hand it might be an option to
unify include operations. So you do only need to know import() and forget
about include, include_once....

What the naming concerns. I think this will change with ongoing bc
deveopment. The extension .php should only be used for code, not for layout.
I think this will change wenn the managers are introduced.

Andi

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[alex b. <en...@tu...>]

> Another one could be:
>
> Leave import for packages as is:
> import('binarycloud.core');
> import('binarycloud.core.Init);
> etc.
>
> add resource handler for true files:
>
> import('file:a_file_name');

why would one not then just use include_once?

i.e. we'd be replicating (unnecessarily, unless your suggestion would do
something different than when I have in mind) functionaliy that php already
takes care of.

_alex

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

Hi Alex,

>> add resource handler for true files:
>> import('file:a_file_name');
> why would one not then just use include_once?
>i.e. we'd be replicating (unnecessarily, unless your suggestion would do
>something different than when I have in mind) functionaliy that php already
>takes care of.

That's right. I wont change the import.  But If you plan to modify import
the way Justin demands this would be the way how I would do it.

Again I would not change import. Include does a fine job, so why adding
overhead.

--
Andi

Re: [binarycloud-dev] Another kneejerk suggestion for import()

[alex b. <en...@tu...>]

> What about this syntax to ship enough information to
> import() in order to distinguish "package" from "file":
>
> import('a_file_name')
>
> for importing a "true file object", and
>
> import('package_name:object')
>
> for importing an "object" from a "package"????

Again, how do I know where to get my file from, _without_ having a map?

and the latter is exactly what we do, minus the ":"

> See, this would suit me.  Maybe not everybody.  I NEVER
> USE A COLON in file names.  Somebody might.  But, I
> would argue that in the great corpus of UNIX conventions,
> using dots in file names probably prevails over using
> colons in file names by at least 100 to 1.  Hell, I
> don't really know that, but I bet you agree...

I suppose we could switch to
binarycloud::core::Perm or something, but I would prefer not to.
this notation:
binarycloud.core.Perm is clean, simple, and easy to write.

> Boff.  I am stopping now with this struggling with
> this problem for the time being and go make my modules
> work on the new r2, and wait for you to get out of
> bed and respond.  Maybe you have already fixed the
> problem in your dreams out there in PST.

I think I'd like odysseas' opinion on the "dots or colons or some other
character as package delimiter" thing.

This is one of the rare cases where I think I am comfortable saying, we need
to have a standard - not a complex one - just, "can't use multiple "." in
filenames" - because we must be able to have some implicit knowledge about
files going through make.

I will play with the "." -> ":" or "::" change.

_alex

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

Hi Alex,

> I will play with the "." -> ":" or "::" change.

vote for the "." It's comfortable. Java uses this and why break with a
standard.

Andi