• 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: email@hidden (Michael Sullivan)
  • Date: Sun, 25 Aug 2002 23:24:16 -0400
  • Organization: Society for the Incurably Pompous

Has writes:

> No, I meant something like this:
>
> ======================================================================
>
> 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() --> "whoops!"
>
> ======================================================================
>
> Script a's 'bar' suddenly starts behaving differently to how it would have
> had b not had a handler called 'foo' also. And since we're not meant to be
> teaching anyone OOP here, why are we suddenly exposing procedural folks to
> *upcalls* of all things?
>
> [Ditto with the "b's parent's foo()" stuff, btw. Module users shouldn't
> ever have to know or use such a beast.]

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 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.


Michael
_______________________________________________
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.

  • Follow-Ups:
    • Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
      • From: Christopher Nebel <email@hidden>
References: 
 >[the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts (From: has <email@hidden>)

  • Prev by Date: Re: Saving Folder Structure's for FMP
  • Next by Date: Re: Interesting observation in OS X scripts menu
  • Previous by thread: [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