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
