# casting question - Page 2

•  Subject
• Author
• Posted on

## Re: casting question

> It looks to me like you ain't using strict because I do not see a
> declaration of $email_line before its first use. it's declarted, otherwie the error would be a little more obvious...i do all my declares at the top of a subroutine (habit) > Oh yes it is. For example, why on God's green earth are you mucking about > with the internals of the Mail::Internet object? define mucking, am trying to pull the values out of the array >You could not have been much of a C programmer not knowing the difference between casting and dereferencing. yeah, let's not go and judge each other on how little we know of each other...you don't know what i have done, gotten paid, gotten recognized for, as the same applies to me looking at you.... if i were to judge you by just your posts, which is all you have of me and laid judgement thereaftrer, i would judge you to be one anti-social, miserable human being, who needs go out and get a girl (or a guy if you refer...i don't judge there either....actually your hostility towards me might tend me to say it's the latter )....but i'll refrain from such judgements till we get to know each other > You do not have a casting question. You have a problem that has been caused > by the fact that you went mucking about the internals of the Mail::Internet > object you created. You are not following good practices. Your posts are > available to the whole wide world to see on Google. If your errors remain > uncorrected, someone, somewhere down the road might see them and think "A- > ha, maybe this is the way to go". All of us are trying to prevent that from > happening. obviosuly OBJECTS are new to me as well as Perl, which is why in my OP i said i clarified that i might have a casting problem... and anyone finding my posts via a google search who would copy from my posts where i say "help me, this doesn't work"...well hey, that's an obvious one... daniel ## Re: casting question daniel kaplan wrote: > obviosuly OBJECTS are new to me as well as Perl So why haven't you read the OOP tutorial that comes with Perl? perldoc perltoot sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org ## Re: casting question > daniel kaplan wrote: > So why haven't you read the OOP tutorial that comes with Perl? and i have, and keep re-reading it (and the references chapter) during breaks....as i explained in a previous POST, it's just a C habit....there's a structure, let's go inside for a look, use what we can, etc. etc. and again, as i said, i have noticed that i am doing that, and will try more diligently to take off my C glasses, and empty my cup of tea, etc... ending this thread, NOW....won't even read another post in it.... i again thank EVERYONE who tried to help, and regardless of attitude to those that poitned me to my actuall error, where today's lesson was that "an object is to be USED, not PERUSED..." daniel ## Re: casting question daniel kaplan wrote: > it's just a C habit....there's > a structure, let's go inside for a look, use what we can, etc. etc. For what it's worth, it's been my experience that the idea of "opaque structures" (aka objects) is becoming more common in C too. Obviously in C you'd write it as "do_something(obj,...)" instead of "obj->do_something(...)", but that's just a trivial matter of syntax. The high-level concept isn't really all that different. The C toolkits I'm most familiar with - Gtk (Linux) and Core Foundation (Mac) - make *heavy* use of the idea. Perhaps it's not as popular in the Windows world you're coming from. > ending this thread, NOW....won't even read another post in it.... Read or not, as you wish, but you're not the boss of this group. You can't end the thread. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org ## Re: casting question > >> It looks to me like you ain't using strict because I do not see a >> declaration of$email_line before its first use.

> it's declarted, otherwie the error would be a little more obvious...i
> do all my declares at the top of a subroutine (habit)

>> Oh yes it is. For example, why on God's green earth are you mucking
>> about with the internals of the Mail::Internet object?

> define mucking, am trying to pull the values out of the array

Not using the object's public interface that is documented in its
documents.

>>You could not have been much of a C  programmer not knowing the
>>difference between casting and dereferencing.

> yeah, let's not go and judge each other on how little we know of each
> other...you don't know what i have done, gotten paid, gotten
> recognized for, as the same applies to me looking at you....

Maybe this one:

http://www.palmbeachpost.com/politics/content/news/epaper/2004/11/05/a29a
_BROWVOTE_1105.html

> obviosuly OBJECTS are new to me as well as Perl,

Sinan.

--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)

## Re: casting question

> > it's declarted, otherwie the error would be a little more obvious...i
> > do all my declares at the top of a subroutine (habit)
>

may i, in all seriousness,  ask why?  to me it just seems to make for neater
code..

> Maybe this one:
>
> http://www.palmbeachpost.com/politics/content/news/epaper/2004/11/05/a29a
> _BROWVOTE_1105.html

wow, that's good, you reached really far for that one....want to resort t
name calling?  fine...can i invite you to do that again personally via my
email?  or would you rather contniue to clutter up the threads here with
more useless name calling...

wow, i just realized....you (and others) scream about the noise level hear,
and how it drives good people away.  yet, whenever i have inited anyone (and
definitly you) to take the insults, and personal stuff to email, you
don't....yet you contniue to write useless posts here...who's really at
fault for making the noise level then?  remember, the least common
denominator in every f-ed up relationship you have ever had, is "you"

TA!

daniel

## Re: casting question

daniel kaplan wrote:

>
>
>>>it's declarted, otherwie the error would be a little more obvious...i
>>>do all my declares at the top of a subroutine (habit)
>>
>
>
> may i, in all seriousness,  ask why?  to me it just seems to make for neater
> code..

If you declare a variable using my, it disappears when it goes out of
scope (which usually means out of the innermost { } pair when it's
created). Thus you use less memory, as the memory can be reused later
e.g. if you end up using several different loop variables.

It also helps prevent other bugs, for example if you had a left over
value in a temp variable from earlier in the sub which you'd forgotten

Re your original question (which now seems to have been solved) - in
general as long as you try to read the relevant parts of the
documentation (i.e. whatever module(s) you're trying to use at the time)
people here don't mind clarifying stuff. But if you're relying on stuff
that's not in the documentation (e.g. poking around, finding 'foo' is an
arrayref that's probably the one you want) may well lead to code that
won't work if the module design changes for some reason. There's no
reason for module writers to keep the internals the same, however
they'll (almost certainly) keep the public interface the same. So you're
(more or less) guaranteed the $IMobj->body() method will always work, but$IMobj-> may not one day for some reason.

## Re: casting question

i said i would stop reading this thread so it would die (i.e. no tit for tat
replies) but decided to read this one post for whatever reason....so perhaps
you'll allow to pick your brain for some clarification?

> If you declare a variable using my, it disappears when it goes out of
> scope (which usually means out of the innermost { } pair when it's
> created). Thus you use less memory, as the memory can be reused later
> e.g. if you end up using several different loop variables.

what i mean is that i am doing the MY's at the top of the subroutine, like
this:

sub QuikRoutine
{
my $each_line; ... ... foreach$each_line
...
...
}

rather than:

sub QuikRoutine
{
...
...
foreach my $each_line ... ... } now if a "my" declared at the topic of a routine is like "static" in C, then i am way wrong, but i undestood it's not.so, in the end, as far as i understand the reading, as soon as i leave the subroutine the memory for$each_line is freed.  if both are the same, is there another "functionality"
reason not to do it my way?  for me it's a preference thing.   but please,
if a = b, let me know.  if it is a matter of a = a, i'll keep doing it my
way...oh one another reason i ended up liking it my way, is that when
debuggng, the moment i left the very line using the "my" in the code itself,
the debugger seemed to lose the old variable, with the new one ready....

and also, this is sort of OT, since a "my" translates to discarding the old,
and making new, wouldn't this just be more processing time when you right it
as      "foreach my $each_line", than the other? >So you're (more or less) guaranteed the$IMobj->body() method will always
work,
> but $IMobj-> may not one day for some reason. this was the "doh!" realization i had yesterday and thanks anyway ## Re: casting question daniel kaplan wrote: > > what i mean is that i am doing the MY's at the top of the subroutine, like > this: > > sub QuikRoutine > { > my$each_line;
>     ...
>     ...
>     foreach $each_line > ... > ... > } > > rather than: > > sub QuikRoutine > { > ... > ... > foreach my$each_line
>     ...
>     ...
> }

My apologies, I should've made this clear. In the second construction,
the "$each_line" variable ceases to exist after the end of the foreach block. This makes sense if you think about it, since you don't (in most cases) need the variable after the end of the loop. If for some reason you wanted to keep the last value from the loop (e.g. you're jumping out of the loop on a certain condition) then your way would make sense. Otherwise you're holding$each_line around until the
end of the sub when you probably don't need to.

> and also, this is sort of OT, since a "my" translates to discarding the old,
> and making new, wouldn't this just be more processing time when you right it
> as      "foreach my $each_line", than the other? I suppose it might (although I don't know enough about inner workings of Perl to comment) but if you're that concerned about processing time you're using the wrong language. I can't imagine it being significant, it may be that the optimiser is clever enough to reuse the same location each time. ## Re: casting question ....snipped.... thanks ## Re: casting question comp.lang.perl.misc: <Daniel's examples> sub x { my$foo;
for $foo ( ... ){} } sub y { for my$foo ( ... ){}
}
</examples>

> now if a "my" declared at the topic of a routine is like
> "static" in C, then i am way wrong, but i undestood it's
> not.so, in the end, as far as i understand the reading, as soon
> as i leave the subroutine the memory for $each_line is freed. > if both are the same, is there another "functionality" reason > not to do it my way? It's not easy to see with the foreach block, but in the second example above,$foo is scoped _inside_ the foreach, not outside.
As soon as the foreach block ends, $foo is out of scope. "my" is definitely not "static"-for-Perl, at least as per my understanding of "static" for C. <snip> > and also, this is sort of OT, since a "my" translates to > discarding the old, and making new, wouldn't this just be more > processing time when you right it as "foreach my$each_line",
> than the other?

I'm not sure what you mean here.  "my" generally doesn't discard
anything, even if you declare a variable in one block which
shadows a variable with the same name in an enclosing block.  As
soon as you exit the inner block, the old variable is back in
scope, untouched (assuming you didn't touch it).  In a for loop,
every iteration writes a new value to the loop variable (which
you must know).  It doesn't have anything to do with the scoping
of the variable.  Are you thinking that $each_line goes out of scope each time through the loop, and that it must be reallocated? >> So you're (more or less) guaranteed the$IMobj->body() method
>> will always work, but $IMobj-> may not one day >> for some reason. > > this was the "doh!" realization i had yesterday and thanks > anyway No offense to the Perl gurus here, but Perl is not the easiest language for learning OOP. You might consider Java (or C++, coming from a C background) for learning OOP and Perl for learning scripting. And Java programmers get paid better :-) Brandan L. -- bclennox \at eos \dot ncsu \dot edu ## OT (Re: casting question) > if i were to judge you by just your posts, which is all you have of > me and laid judgement thereaftrer, i would judge you to be one > anti-social, miserable human being, who needs go out and get a girl > (or a guy if you refer...i don't judge there either....actually your > hostility towards me might tend me to say it's the latter )....but > i'll refrain from such judgements till we get to know each other Daniel: I do not think you understand the implications of what you are saying sometimes. You like to directly go to personal insults. This behavior will not make me any more charitable towards you. As the saying goes, once is happenstance, twice coincidence, thrice is enemy action. You have gone way beyond three. Sinan. -- A. Sinan Unur 1usa@llenroc.ude.invalid (remove '.invalid' and reverse each component for email address) ## Re: OT (Re: casting question) >You like to directly go to personal insults. This behavior > will not make me any more charitable towards you. As the saying goes, > once is happenstance, twice coincidence, thrice is enemy action. You have > gone way beyond three. i'm sorry sinan, what was this then that you wrote? >>You could not have been much of a C programmer not knowing the >>difference between casting and dereferencing. go look in the mirror...and tell me who threw out personal insults daniel ## Re: OT (Re: casting question) X-Ftn-To: daniel kaplan >>You like to directly go to personal insults. This behavior >> will not make me any more charitable towards you. As the saying goes, >> once is happenstance, twice coincidence, thrice is enemy action. You have >> gone way beyond three. > >i'm sorry sinan, what was this then that you wrote? > >>>You could not have been much of a C programmer not knowing the >>>difference between casting and dereferencing. > >go look in the mirror...and tell me who threw out personal insults Why should observation of the obvious be considered as an insult? I'm reading relevant material when lacking understanding; as it seems to me, that should be the shortest path to filling the gaps in knowledge. -- Matija ## Re: OT (Re: casting question) > > >You like to directly go to personal insults. This behavior > > will not make me any more charitable towards you. As the saying goes, > > once is happenstance, twice coincidence, thrice is enemy action. You have > > gone way beyond three. > > i'm sorry sinan, what was this then that you wrote? > > >>You could not have been much of a C programmer not knowing the > >>difference between casting and dereferencing. > > go look in the mirror...and tell me who threw out personal insults That's not an insult, it's an observation based on what you wrote. (I had the same impression.) To refute it, show that you *do* know the difference. Complaining about rudeness won't convince anyone. Anno ## Re: OT (Re: casting question) daniel kaplan wrote: > > i'm sorry sinan, what was this then that you wrote? > >>> You could not have been much of a C programmer not knowing the >>> difference between casting and dereferencing. > > go look in the mirror...and tell me who threw out personal insults Ummmm, to me, Sinan made a perfectly valid statement. It's like saying "you can't be much of an astronaut if you haven't been into space". Casting and de-referencing are enormously different. If you made a simple mistake in choice of words, explain and your position will be accepted. If you are surprised by the claim, check out a book or two. Either way, leave the ego out of it. Anyway, this is why I rarely visit perl newsgroups unless I have a question I cannot answer myself. It's such a wasteland of brittle personalities and abuse. What's Duncezilla's current handle? I'm out of here. Thanks for all the fish. ## Re: OT (Re: casting question) Andrew Hamm wrote: > Anyway, this is why I rarely visit perl newsgroups unless I have a > question I cannot answer myself. It's such a wasteland of brittle > personalities and abuse. What's Duncezilla's current handle? Purl Gurl? Haven't seen her in a long while, but I don't read most postings anyway. No time :-( -- John Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html ## Re: casting question daniel kaplan wrote: > obviosuly OBJECTS are new to me as well as Perl, which is why in my > OP i said i clarified that i might have a casting problem... Now, in which way could objects and casting possibly be related? The one has absolutely nothing to do with the other. The only place in Perl where you might find something like "casting" is to add a 0 to get the numerical value of a scalar or append an empty string to get the text value. But even to call that casting would be a stretch. jue ## Re: casting question Jrgen Exner wrote: > The only place in Perl where you might find something like "casting" is to > add a 0 to get the numerical value of a scalar or append an empty string to > get the text value. But even to call that casting would be a stretch. I'd say that blessing an ordinary reference, or re-blessing an object into a different class, would be the closest thing that Perl has to type casting. That's still a stretch though. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org ## Re: casting question daniel kaplan wrote: >>declaration of$email_line before its first use.
>
> it's declarted, otherwie the error would be a little more obvious...i do all
> my declares at the top of a subroutine (habit)

In perl that is a bad habit.

A variable that is going to be valid only inside the body of a foreach
loop should be as such:
foreach my \$variable (@list) { expr; expr; }

Variables should be declared in the smallest scope possible, in order
to help the compiler to detect typographical errors for you.
When a variable goes out of scope, the memory that had been allocated
to it can be re-used.
-Joe