The-wanted-function
[Jatin] Thanks Chas , I would definitely explore more on different
modules available at CPAN , that is a great place. Appreciate your help
in making me understand about Callbacks.
Thanks
Jatin
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional comman
On Thu, Sep 9, 2010 at 12:35, Jatin wrote:
>
>> File::Find's interface is through its package variables.
>
> [Jatin] So my subroutine that i use with the File::Find's find method has
> access to the package variables ? Correct me if i am wrong.
>>
>> It is a very
>> bad design and is much regret
On Thu, Sep 9, 2010 at 12:49, Jatin wrote:
>
>> The callback is printing the value of $File::Find::name (which, again,
>> is set by the File::Find::find function before the callback is
>> called).
>>
>>
>>
>
> [Jatin] Chas , when you say that the File::Find's find method sets its name
> variable b
On 9/9/10 Thu Sep 9, 2010 9:49 AM, "Jatin"
scribbled:
>
>> The callback is printing the value of $File::Find::name (which, again,
>> is set by the File::Find::find function before the callback is
>> called).
>>
>>
>>
> [Jatin] Chas , when you say that the File::Find's find method sets it
On 9/9/10 Thu Sep 9, 2010 9:35 AM, "Jatin"
scribbled:
>
>> File::Find's interface is through its package variables.
> [Jatin] So my subroutine that i use with the File::Find's find method
> has access to the package variables ? Correct me if i am wrong.
>>It is a very
>> bad design and is
The callback is printing the value of $File::Find::name (which, again,
is set by the File::Find::find function before the callback is
called).
[Jatin] Chas , when you say that the File::Find's find method sets its
name variable before the callback is called , Do you mean that this
"name"
On Thursday 09 September 2010 08:38 PM, Shawn H Corey wrote:
On 10-09-09 10:59 AM, Chas. Owens wrote:
$File::Find::name is a package variable from File::Find.
$File::Find::name is a fully-qualified variable, just in case you're
wondering what "fully qualified" means.
[Jatin] No , i act
File::Find's interface is through its package variables.
[Jatin] So my subroutine that i use with the File::Find's find method
has access to the package variables ? Correct me if i am wrong.
It is a very
bad design and is much regretted, but there is nothing to do about it
now.
[Jatin]
On 10-09-09 10:59 AM, Chas. Owens wrote:
$File::Find::name is a package variable from File::Find.
$File::Find::name is a fully-qualified variable, just in case you're
wondering what "fully qualified" means.
--
Just my 0.0002 million dollars worth,
Shawn
Programming is as much about
On Thu, Sep 9, 2010 at 10:25, Jatin wrote:
>
>> Hi Jatin,
>>
>> A callback is a reference to a subroutine.
>
> [Jatin] if a callback is a reference to a subroutine then it can be stored
> in scalar variable to call that subroutine. Am i correct in my understanding
> ?
Yes, all types of references
then how come the execution of
our callback subroutine returns the complete path of the file name ?
Please clarify on these points.
Thus, your subroutine is able to get each item in the
path as soon as they are encountered by File::Find's find(). If find() was not
implemented to hand
> Hi
>
> I am a newbie to Perl , I was reading through one of the beginner level
> books on perl. I did not understand the concept of "Callbacks" and i
> have the following questions on it:
>
> 1. What are they ?
>
> 2. Why do we need them ?
>
On Thu, Sep 9, 2010 at 07:20, Jatin Davey wrote:
> Hi
>
> I am a newbie to Perl , I was reading through one of the beginner level
> books on perl. I did not understand the concept of "Callbacks" and i have
> the following questions on it:
>
> 1. What are they ?
>
Hi
I am a newbie to Perl , I was reading through one of the beginner level
books on perl. I did not understand the concept of "Callbacks" and i
have the following questions on it:
1. What are they ?
2. Why do we need them ?
3. What useful purpose do they achieve ?
I was r
> On Thursday 12 Feb 2004 4:19 pm, James Edward Gray II wrote:
> > On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote:
>
> >
> > The choice is, of course, yours.
> >
> > If you're going to tie all these things together like that though and
> > keep track of everything, I think you should take Wi
On Feb 12, 2004, at 11:25 AM, Gary Stainburn wrote:
I am aware of this and have taken on board the things you've said
before.
Rethinking which object performs which task will help reduce the need
to loop
backs. For instance having a lever drive a gantry which drives a
signal
eliminates the nee
On Thursday 12 Feb 2004 4:19 pm, James Edward Gray II wrote:
> On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote:
> > I can understand the point that James made, in that the update of the
> > Trainset
> > objects is being made by a Tk event trigger, and could therefore simply
> > update the screen
On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote:
I can understand the point that James made, in that the update of the
Trainset
objects is being made by a Tk event trigger, and could therefore simply
update the screen at the same time, e.g. clicking on a lever throws a
signal
*and* updates the
On Tuesday 10 Feb 2004 10:41 pm, Wiggins d Anconia wrote:
> > On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:
> > > Hi folks,
> >
> > Hello again.
> >
> > [snipped history]
> I hate beating a dead horse... but this discussion of your callbacks and
>
On Wednesday 11 Feb 2004 2:54 pm, R. Joseph Newton wrote:
> James Edward Gray II wrote:
> > On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:
> > > Hi folks,
> >
> > Hello again.
> >
> > [snipped history]
> >
> > > One of the points made in the previous threads was that there should
> > > be no
>
James Edward Gray II wrote:
> On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:
>
> > Hi folks,
>
> Hello again.
>
> [snipped history]
>
> > One of the points made in the previous threads was that there should
> > be no
> > need for sub-classes to have a link back to it's parent, and through
> >
a refresh.
>
> Be aware, if the GUI allows changing the Trainset and the model
> controller is changing the Trainset, you make have concurrent access
> issues to deal with.
>
> Well, maybe that will give you some new ideas.
>
I hate beating a dead horse... but this discussio
On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote:
Hi folks,
Hello again.
[snipped history]
One of the points made in the previous threads was that there should
be no
need for sub-classes to have a link back to it's parent, and through
the
correct splitting of functions (inter-instance in clas
Hi folks,
Thanks to previous threads on this list, I'm making pretty good progress on
what is my first OOP project. The improvements I've made after feedback are:
* logical bounderies between containers and contents (sub-classes)
* nicer interface functions
* (starting to use) named parameters,
24 matches
Mail list logo
