: : Nah, I'm not a fan of "New Age" ish stuff either.
Whether
: : God is a seperate thing from the universe isn't a question I'd
: : really thought about before though.
:
: Glad I could expand your horizons
Of course, if God is everywhere at once, then that means that (s)he must be in the universe... Or maybe it doens't work like that.
: : : : The scientific version is, as you say, more interesting though.
: : : : Not sure the only way we can get to know it is science though,
: : : : unless you broaden your definition of science...
: : : Science seeks to understand what is. If all that is is God, then
: : : science is the way to understand God.
: : Sounds to me like this is turning science into a religion...
:
: That's certainly an inherent risk in this type of thinking.
:
Indeed. It's amazing how many people have blind faith in science too, which I'd say comes down to the same thing. I guess it's the way it's taught at school in part - as the truth. "Evolution theory is correct" vs "Evolution is the best theory we have at the moment".
: : The only reason we can't test whether there is a God or not is
: : becasue we don't know how to.
:
: And because it wouldn't matter if we did.
Wouldn't it? What if we (somehow) found proof that there WAS a God? Don't you think a lot of people would all of a sudden take up some religion or other?
: Have I ever told you that I have a dragon living in my garage?
: Would you like to see it? Sorry, he's invisible. Would you like to
: see his footprints? Sorry, he floats. Would you like to touch him?
: Sorry, he's incorporeal. Would you like to see food disappear that
: he's eating? Sorry, he gets his energy through non-physical means.
: See? For every possible test, there's an excuse.
And...uh...how do you propose to test whether God is there? If you come up with one, I'll try and come up with an excuse...
: : Just because we don't know HOW to do something doesn't mean it
: : can't be done.
:
: True, but not the point.
:
Why isn't it the point? If we could do a test to see whether there was a God, we probably wouldn't be having this discussion because the test would have given the answer. We don't currently know of a test we can carry out to answer that question.
: : : : : : Ok, on "revelation" too.
: : : : : Now you're talking...
: : : : Which is a wholly unreliable method for obtaining truth.
: : : It could be true though!
: : : Or sleep deprivation or d r u g-induced hallucination or
: : : schizophrenia or...
: : God.
: Occam's Razor is not on your side here.
Nah, I felt God was necessary. :-P
: : : : You can also compile the code for a method on-the-fly if need be, and
: : : : generate property accessors on the fly.
: : :
: : : Yep and yep.
: : Through eval style constructs?
:
: I think so. This isn't something I've ever done before. I may be
: overstating Python's capabilities here without having a good idea
: what we're talking about. I can research if you like.
Only if you'd like to.
In Perl a "class" can have an AUTOLOAD method that is called if a method that is called cannot be found. Therefore you can compile that method "on the fly" and insert it into the namespace's symbol table. Good thing is that, AFAIK, once you've compiled it, future calls to it have no extra overhead that you would not get on a method compiled in the beginning. You can use these to save you writing a lot of property get/set style methods too! (Or you can read the instance data directly like I do, because method calls can't be interpolated in Perl5...nope, I wouldn't make an OO purist).
: : That's possibly something over Perl there; I don't know that you
: : can have more than one class per namespace (called a package in
: : Perl), as the object is created by taking a reference to a data
: : structure and associating it with a given package (e.g. all the
: : subs in that package).
:
: Python has modules (files) that can be imported and treated sort of
: like global objects. A module, though, can contain as many classes
: as you like.
So you must be able to declare a set of subs (methods) as belonging to a particular class. In Perl, you can only declare them as belonging to a particular namespace. You can however have more than one namespace defined in a single file. Convention is that you have a file for each though, and a matching directory structure.
: : I think of it as variable type is the type of the container, and
: : value type is the type of the value inside the container. I think
: : maybe using variable type to describe hashes, arrays and scalars
: : might well be an abuse of the term variable type, though.
:
: In that case I would say that Python has no variable types, but has
: strict value typing. Variables are just names which point to
: values. Python has lists and dictionaries and scalar types, but any
: name can reference any of them.
Hmmm...in Perl an array is just a collection of scalars indexed by number and a hash is a collection of scalars indexed on a certain key. A scalar can hold a reference to another scalar, array, hashref, sub (named or anonymous) or typeglob. In Perl we have sigils though, e.g. $scalar, @array, %hash. I think Python doesn't have these?
: : : In Python, the type of a variable isn't determined until
: : : it's set to something. Once it's set, however, the type is
: : : important. You can't, for instance, add an integer and a string
: : : with the + operator (type mismatch). You can, though, add
: : : (concatenate) two strings or even multiply a string by an integer
: : : (repeats the string N times).
: : Seems like a curious half way house to me. A variable's type
: : isn't important till it's set to something, which may often happen
: : at runtime. Thus, you end up with a kind of strictish typing in
: : some places, but don't gain the benefits of compile time type
: : optimisation in (most,any) cases? Taking the integer and string
: : example, what if the function that read data in gave you a string
: : and you wanted to add it to another number? Is there a
: : numification operator or do you have to cast it or what? (This is
: : another good reason for having different operators for
: : concatenation and addition).
:
: I agree that usually different operators for concatenation and
: addition is a good thing, but in Python's case I would disagree.
: Especially since you can multiply strings to repeat them.
You can do that with the x operator in Perl.
print 'a' x 5; #print aaaaa
I ain't used it all that much, though it's useful to have it there.
: You can cast a string to a number using the int() function. Numbers
: can be cast to strings using either str() or back-ticks `100`.
Hehe...don't try that in Perl. Anything between back-ticks gets executed! Sounds a bit like VBs approach in a way. I still ain't decided how much I like the C# appraoch to casting...
float a = 2;
int b = (int) a;
: I've heard rumors that future versions of python may include compile-
: time typing, but I think I remember reading that Guido was against
: that. I'm not sure.
It's only going to be optional in Perl6. I'd be pretty upset if it was compulsary to use strict typing all the time!
: : : If I had a class named Foo, to create an object of type Foo I would
: : : do:
: : :
: : : f = Foo()
: : Is it me, or does that look an awful lot like a function call,
: : collecting the return value in f?
:
: That's exactly what it is. The () are bascially the "call"
: operator. Classes automatically have the call operator mapped to
: their constructor.
Interesting. I've never known the () being thought of as a call operator...I guess it means you can't call parameterless methods without a () though? Curious, but makes a lot of sense.
: : Or does it work on the basis that a class has a constructor that
: : is the same name as the class and the constructor actually returns
: : the object?
:
: Actually, constructors are always named __init__(). Maybe this will
: help the metaclasses thing become clearer. In Python, when you
: issue a "class" statement like this:
:
:
: class Foo(object):
: a = 100
: b = 'cat'
: def __init__(self, foobar='foobar'):
: self.foobar = foobar
: def __repr__(self):
: return `self.foobar`
: def printme(self):
: print self.foobar
:
What's __repr__?
:
: ... the interpreter gathers the methods (def statements) and members
: (a, b) into a dictionary, makes a list of superclasses (object) and
: passes these two items plus the name ('Foo') to the metaclass
: constructor which creates an object named Foo that returns new
: instances of itself when it is called.
:
: Maybe that just confused things.
<laughs> Maybe it was competing for the world's longest sentence? I sort of get it... The list of superclasses is essentially a list of objects instantiated from that class, and the dictionary contains the blueprint for the new object. The metaclass takes these, creates the object, adds it to the list of superclasses, and returns the object it's created? So basically the metaclass controls object construction for many classes?
: Maybe it would help if you think of class statements as creating
: object factories? Objects that return new objects.
That's an easy enough concept, because you essentially write the code that manufactures the object in Perl.
#I'll call the constructor new; call it anything suitable.
sub new {
#Get invocant.
my $invocant = shift;
#Create a data structure of some sort.
my %hash = (
somekey => 'somevalue'
);
#Create a reference to it.
my $hashref = \%hash;
#Bless the reference - that creates the object.
bless $hashref, $invocant;
#Return the created object.
return $hashref;
}
You can write it more compactly, of course.
: Really, though, you don't have to think about all this stuff if you
: don't want to.
That's my problem. I LIKE to think about all this stuff!
: : : Now I have an object named "f" in the current namespace that
: : : references a Foo object. Never had to declare f, though. I could
: : : immediately set f = 3 and have an integer variable.
: : Yeah, you can do that kinda thing in Perl. In Perl6 though you
: : will be able to forbid stuff like that, and have proper typing.
: : Which is a Good Thing for helping prevent stupid bugs and stuff,
: : though I'm pleased it's an option, and not enforced!
:
: I find Python to be very "zen". For all my career I've had
: languages enforce typing, and now Python has stripped away so much
: of that (artificial) structure. I love it.
Yeah, that's why I love Perl too. Freedom. Perl6 will be even better, as it allows me to be harsher on myself when appropriate by using strict typing, but without sacrificing the freedom I have to not care about typing when it's not going to cause any problems not caring. Long live languages like this.
Jonathan
###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");
