Bill wrote
> each class should be contained in 1 file and with the same name as the
class defined
I didn't know that. I'll bear it in mind.
A glance at my repos shows I stick to that convention anyway. At least for
my major classes.
On Fri, 12 Apr 2019 at 03:39, bill lam <bbill....@gmail.com> wrote:
> If you follow java's dogma that each class should be contained
> in 1 file and with the same name as the class defined, then it
> will be easier to blame.
>
> Thu, 11 Apr 2019, Ian Clark написал(а):
> > Henry wrote:
> > > …and a global assignment only for the place that you know is the top
> > level?
> >
> > Trouble is, if you're using JQt IDE to maintain an addon, the top level
> > changes.
> > ++ During development, it is your buildfile: /myaddon/source/build.ijs.
> > ++ But once a user downloads it via pacman, it is myaddon.ijs
> >
> > Maybe it's safe enough to use MYDIR=: in both build.ijs and myapp.ijs.
> But
> > "safe enough" is not in my vocabulary now I've been bitten.
> >
> > Maybe again, it's only a problem for someone like me using JQt to
> develop a
> > suite of addons which need to be maintained in-tandem. But that someone
> > commands special attention due to the damage s/he can inflict.
> >
> > I'm repeatedly drawn back to the idea of badging a script with its full
> > path. No levels of indirection.
> > ++ The huge advantage is diagnostic: if bugs are regressing and you think
> > it's due to the wrong version of a script being loaded, then there's a
> > complete and effective procedure for guarding against it, and checking
> > whether it has happened.
> > ++ The huge disadvantage is that if a script is moved, it's not clear who
> > or what has the duty to alter the badge. But it's easy at several
> different
> > stages to detect that the badge is wrong. And there's never the slightest
> > doubt as to what the badge should be.
> >
> > Ian Clark
> >
> > On Wed, 10 Apr 2019 at 23:44, Henry Rich <henryhr...@gmail.com> wrote:
> >
> > > Then why not use
> > >
> > > MYDIR =.
> > >
> > > in each script, and a global assignment only for the place that you
> know
> > > is the top level?
> > >
> > > Henry Rich
> > >
> > > On 4/10/2019 5:15 PM, 'Pascal Jasmin' via Programming wrote:
> > > >
> > > > I think its about global name sharing and clobbering each other
> > > >
> > > > MYDIR =: pattern to set current dir
> > > >
> > > > load 'MYDIR/subdir/file1.ijs' (will change MYDIR if same name used
> to
> > > track)
> > > >
> > > > load 'MYDIR/file2.ijs' (wrong MYDIR)
> > > >
> > > > one solution is to repeat the anonymous 4!:4 { 4!:3 expression
> instead
> > > of assigning its result. The other is to organize files into a sense
> of
> > > hierarchy such that global variables TOPDIR, MAINSUBDIR are part of the
> > > application and may always be set before "deep" files are loaded.
> > > >
> > > > A somewhat related request (already at System/Interpreter/Requests
> ) is
> > > to allow an optional left arg to 0!:n , but on second thought, the only
> > > relation is to remind you of it :P
> > > >
> > > >
> > > > On Wednesday, April 10, 2019, 12:57:54 p.m. EDT, Henry Rich <
> > > henryhr...@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I was thinking the same thing, and when I look in the interpreter, I
> > > > find that the script index IS stacked and restored in jtlinf().
> > > >
> > > > Can someone show a simple example of how the script-index field in an
> > > > entity gets corrupted?
> > > >
> > > > Henry Rich
> > > >
> > > > On 4/10/2019 11:23 AM, Raul Miller wrote:
> > > >> As described, that will work for scripts in the same folder, but
> will
> > > >> break if those scripts require or load scripts from different
> folders
> > > >> which implement the same mechanism.
> > > >>
> > > >> What seems to be missing here is use of a stack for tracking this
> > > >> external dependency (and I think it has to go into the
> implementation
> > > >> of the interpreter, though putting something into the implementation
> > > >> of 'load' could do the trick).
> > > >>
> > > >> Thanks,
> > > >>
> > > >
> > > > ---
> > > > This email has been checked for viruses by AVG.
> > > > https://www.avg.com
> > > >
> > > >
> > > >
> ----------------------------------------------------------------------
> > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > >
> ----------------------------------------------------------------------
> > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > >
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
