• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts


  • Subject: Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
  • From: Christopher Nebel <email@hidden>
  • Date: Sun, 25 Aug 2002 22:43:30 -0700

On Sunday, August 25, 2002, at 08:24 PM, Michael Sullivan wrote:

script a
property x : "a"
on foo()
return x
end foo
on bar()
foo()
end bar
end script

script b
property parent : a
property x : "b"
on foo()
return x
end foo
end script

b's bar() --> "b" (for some reason, has had "whoops!")

Now what I'd say here, having done a little OOP, is that the result of
*your* script is correct, it's what happens when b doesn't have a
"foo()" that doesn't make sense.

B Taking A as a parent says that B is making itself like 'a', except for
whatever is in B's declaration. Since 'b' has a 'property x', that
should override anything in 'a' whenever an instantiation of b is
called. The problem is that AS doesn't resolve this down the call tree,
so if there's a function in a that's not defined in b, execution
essentially heads over to a, and pays no attention to anything in b.

Although, that's not completely true. It's interesting is that when bar
calls foo(), it jumps back to b if foo is overriden (as it should, IMO),
but if it's not in a 'b' overridden function, it doesn't honor the
property override.

I wonder if that's always consistent, functions override always, but
properties only override if you're in an overridden function.

This is actually a serious bug (or maybe design flaw?) in the OO
implementation, IMO. It would begin to matter if between the stack
issues and compilation, AS ever became a legitimate candidate for really
large scale projects.

It's actually even more complicated than that. If you change foo() to say "return my x", you get "b", which makes sense -- "me" is always the object the message was originally sent to (aka the current script object), not the lexically enclosing object, so even though you're in a method of a, you get b's x.

There may be some special rule about this -- if you you say "my", then you get the current script object's properties; if you don't, you get the lexically enclosing one's? -- but I didn't see anything in a quick scan of the ASLG. (It *did* mention that if you're going to refer to an inherited property in a child script, you have to use "my", or it'll think you're using a local variable.) I'll have to do a little more research.


--Chris Nebel
AppleScript Engineering
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts (From: email@hidden (Michael Sullivan))

  • Prev by Date: RE: script to remove spaces and text in multiple file names
  • Next by Date: Interacting with Project Builder via AppleScript
  • Previous by thread: Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
  • Next by thread: Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
  • Index(es):
    • Date
    • Thread