At some point as the 20th century progressed, the prefix super- (see node) broke away to become an independent word which eventually came to mean essentially the same thing as "good" or "neato" or "cool". Typical usage would be something like "That's super!". My personal theory-- although maybe we should ask William Safire or something-- is that we can blame this particular usage on Superman. What i would guess is that your average colloquial person saw Superman and his Super-powers and Super-strength and Super x ray vision, and knowing nothing of latin word roots began to simply associate "super" in their minds with "powerful". This is, of course, just a guess, and i'm probably wrong. all that is certain is that at some point after Webster 1913, the usage of super became not only colloquial, but often downright idiotically irritating, with the problem reaching its horrific peak when, at some point in the 50s, some horribly evil bastard decided to contort "super" into the more extreme and completely horrific "super-duper", promptly causing the english language to completely lose what tiny amount of dignity it had left. As of this writing "super" has returned to its proper place as being a prefix meaning "greater than or beyond", although as a result of that whole thing with the 50s it is generally treated as a separate word rather than a prefix-- i.e. super wal-mart, or would you like me to super size that extra value meal?

The japanese have taken on "super" as one of those english words they have completely obsessed with, tacking it onto words and phrases in all kinds of crazy places, some of which upon examination make no sense. The Japanese have started doing that kind of thing for some reason, integrating tiny chunks of english not because of any kind of osmosis or cultural imperialism is taking place, but just because it sounds weird. Like, according to this book on japanese slang that this guy i know was reading, it is now common for japanese schoolgirls (who don't speak english) to use "supa eilien" (pronounced like that) as an insult. "Super Alien"? What? Do they know what they're saying? The Japanese usage of super, however, is generally the "correct" one, even when it seems oddly unnecessary (Super Nintendo, Super Seya-jin, Super Catgirl Nuku Nuku, super deformed, etc) and at least partly as a result of their adoption of the word (and the fact that people think that things that seem japanese and bizarre are cool), the word "super" has been dragged back from its gimpy horrific 50s stint as an adjective to become a powerful prefix again, one with the power to bestow instant bizarre kitzch powers onto damn near anything. (See Super Furry Animals, Super Tensile Solids, superbad, Soy super bien soy super super bien soy bien bien super bien bien bien super super, etc.)


In Objective C, "super" is the name of any given object's superclass. It's addressed as a semi-real "object", and is kind of companion to the self object; in fact, super is self, with the difference that any methods called within super will be executed as defined by the parent class rather than as defined by the current class. Super is very important; if you overload methods in a child object, you must call the same method within super in order for the parent implementation to be run-- objc will not do it for you. C++ automatically calls the parent implementation of an inherited function after the overloaded version is run; objc, however, requires the programmer to call the parent's method explicitly, and gives her the option of doing so whenever in the overloaded method she wants.

So in important methods like init, you get just this kind of chain where each layer of an object's inheritance peels back, each implementation of (for example) - init ending by returning [super init]; and thus passing back the init message up the class hierarchy until NSObject is reached.

Super class vessels are ferries that serve the Washington State Ferry system. They have a length of 382', a beam of 73', a draft of 18', and weigh 2813 tons. They can carry up to 2500 passengers and 160 vehicles at up to 20 knots. The vessels serving the WSF fleet are MV Elwha, MV Hyak, MV Kaleetan, and MV Yakima.

Source: WSDOT web site

One of the most basic concepts of object oriented programming is that of inheritance, in which we think of the IS-A property and say that thing A is a thing B, but different or more specific in certain ways. For example, a toothbrush is a dental hygiene instrument.

Inheritance leads us to speak of subclasses and superclasses. (A class is a way of abstracting the properties of a kind of object, while a class instance (or object) is an actual item of that kind; e.g., you could have a class called Toothbrush, of which there may be four instances hung in the rack by your bathroom sink.) The terms are not absolute, but rather form a relationship between two classes (class DentalHygieneInstrument being a superclass of class Toothbrush). Every instance of the subclass can also be considered (though not exclusively) as an instance of the superclass.

This can be useful because some or all of the code that a programmer writes to manipulate objects of the superclass also applies to objects of its subclasses, even if they weren't implemented (or even being considered) when the code was written. The Sterilize method of a DentalHygieneInstrument works for a Toothbrush as well as for a Burnisher. But this is not always the case.

After all, while a Toothbrush is a DentalHygieneInstrument, it is not a Burnisher (which is also a DentalHygieneInstrument), so clearly all DentalHygieneInstruments are alike in many ways, but different in some ways. Perhaps the sterilization procedure for a Burnisher involves first roughing up the surface with sandpaper[1] before performing the usual (common) procedure. While the Toothbrush class will not define a Sterilize method of its own (causing the language to search upward through the inheritance hierarchy until it finds one to use), Burnisher must do so. But there is no need to reproduce the code found in DentalHygieneInstrument's Sterilize method in the Burnisher class; instead, Burnisher's Sterilize can first sand itself, and then invoke the Sterilize method from its superclass.

class Burnisher(DentalHygieneInstrument):
    def Sterilize(self):
        self.SandTip()
        DentalHygieneInstrument.Sterilize(self)
This is an example of the near-universal rule that a subclass's method which overrides a method of a superclass should call the overridden method, either before or after it does its own thing. Notice that that code cannot use self.Sterilize() because that would call its own specialized method, rather than the shared one from the superclass. Now some languages give you a shortcut for doing that. For example, in Java, we can write super.Sterilize(). Java knows that the superclass is DentalHygieneInstrument, so it knows to which method that expression is referring.

That shortcut, however, is not all that useful. It saves a few keystrokes, and it doesn't have to be changed if the code is copied to another class. But it falls down in the face of multiple inheritance.

My examples will change now; I've run out of gas on the dental instrument thing….

Multiple inheritance enters the picture when we have a Thing A that not only is a Thing B, but also is a Thing C (which B is not). Sometimes, B and C are quite unrelated concepts – in which case A is often called a mixin class – and sometimes not. More on that in a moment. Time for a diagram:


        class B     class C
            \         /
             \       /
              \     /
               \   /
                \ /
              class A
In light of the rule about calling your superclass's method from your own overriding one, we can see that a method in A may have to call the same method in both B and C. (In a mixin scenario, it is often the case that a particular method is known to be inherited only from one or the other.) Clearly, the super keyword will not do here. So, for a method M, an overriding implementation in A will look like:
class A(B, C):
    def M(self):
        B.M(self)
        C.M(self)
        # do A's M stuff here
In fact, in earlier versions[2] of Python, if A wanted the M of both B and C to be called, it had to implement its own M even if it had nothing to add, because Python would automatically call only one of them. That's a bit yucky, but wait! Another large wooden shoe is about to be thrown into the mix. Let's get a bit more personal about A, B, and C:

        class Cumulus     class Nimbus
            \               /
             \             /
              \           /
               \         /
                \       /
                 \     /
                  \   /
                   \ /
            class CumuloNimbus
What does this suggest to you? What am I holding back? Remember I said that a mixin class inherited from two unrelated classes. When the superclasses are clearly related, it is not a mixin. Cumulus and Nimbus are obviously related — because each is a subclass of … drum roll …

               class Cloud
                   / \  Scud
                  /   \ Save
                 /     \
                /       \
               /         \
              /           \
             /             \
            /               \
        class Cumulus     class Nimbus
       Save \               / Rain
             \             /  Save
              \           /
               \         /
                \       /
                 \     /
                  \   /
                   \ /
            class CumuloNimbus

This diagram shows the genesis of the aptly-named diamond problem. Consider a method being called with an instance of CumuloNimbus. It we're calling cn.Scud(), that's not a problem: Scud is a method of Cloud and is not overridden by any of these other classes, because clouds all scud across the sky in the same way.

But in the face of reimplementations or extensions, problems occur. Consider a call to cn.Rain(). This is not a problem, because neither Cumulus nor Cloud defines Rain, so the method implemented by Nimbus will be used. Calling cn.Save, on the other hand, is a different kettle of fish. (Let's assume Save is a method that saves the object's data to an open file.) We need to add a Save method to CumuloNimbus, so that it can call Cumulus.Save and Nimbus.Save, in accordance with our rule about calling the overridden method. And it's obviously very important that they both get called, because our cn object may contain data defined by Cumulus, Nimbus, and even Cloud. So we add

class CumuloNimbus(Cumulus, Nimbus):
    def Save(self):
        Cumulus.Save(self)
        Nimbus.Save(self)
and heave a sigh of relief. (In this example, it doesn't matter whether CumuloNimbus adds more data that needs to be saved.)

Oh, no! Remember how diligent we all are when it comes to calling the method in the superclass when we override it? Let's look at the sequence of methods that get called when we do a cn.Save():

    CumuloNimbus.Save
       Cumulus.Save
          Cloud.Save
       Nimbus.Save
          Cloud.Save
The Save method in Cloud got called twice! Depending on the nature of the method, this may or may not be a problem; in this case, it clearly is. Note that if we call Save on an instance of Cumulus, there is no problem, yet the situation is intolerable when called with cn, which is a Cumulus!

While he was creating version 2.2 of Python, Guido noted that this problem could become much more prevalent than it had been previously, because the addition of an ultimate superclass – which earlier Pythons did not have – could cause diamonds to appear where they had not been before, even in the absence of the application creating them; namely, in the situation with A being a subclass of B and C, B and C might now (and should) be subclasses of object.

He wouldn't put us in such a fix without hope, though. A new builtin function called super will be our salvation. It can be used by our various classes to call overridden methods in a safe and complete way. How can it do this? Through its knowledge of the method resolution order.

The method resolution order is a list associated with each class that tells it where to look for an attribute when an instance does not include it; this list is built when the class statement is compiled. In previous Pythons, the MRO for our diamond above would be [CumuloNimbus, Cumulus, Cloud, Nimbus, Cloud] The presence of Cloud in the list twice was never a problem, because the search would never find the attribute in the second one if it hadn't found it in the first one already. At version 2.2, these duplicates are removed, and our MRO is now [CumuloNimbus, Cumulus, Nimbus, Cloud] This ordering is easily derived from the previous one, by retaining only the last occurrence of any class that appears more than once. The super function can use the MRO, together with the class of an instance, to unambiguously determine which class should be called next. It is important to remember here that, e.g., when the Save method in Cumulus is executing, its self may refer to either a Cumulus instance or a CumuloNimbus instance; its code doesn't need to care which (if it did, the whole inheritance idea would be useless), but super, under the covers, cares very much.

A class X always uses super in the same way: the two arguments it passes are always itself (class X) and self. The function then returns an object through which the appropriate implementation of the sought attribute can be found. So, let's look at the implementation of our various Save methods:

    class Cloud(object):
        def Save(self):
            # do actual saving, no overridden method to call
    class Cumulus(Cloud):
        def Save(self):
            super(Cumulus, self).Save()
            # now save Cumulus-specific data
    class Nimbus(Cloud):
        def Save(self):
            super(Nimbus, self).Save()
            # now save Nimbus-specific data
    class CumuloNimbus(Cumulus, Nimbus):
        def Save(self):
            super(CumuloNimbus, self).Save()
            # now save CumuloNimbus-specific data
Did you notice that, unlike our previous examples, there is only one call to super in CumuloNimbus's Save? This is the case no matter how many superclasses it has, because the super mechanism causes every Save method in the hierarchy to be called, once and only once[3]. It does this by looking at the MRO of the class of the instance (not the class whose code is executing), locating the executing class within that list, and making the next entry the starting point for the search for the attribute. Consider the super call in Cumulus.Save. If self is an instance of Cumulus, the MRO is [Cumulus, Cloud] and super determines that Cloud is the place to begin looking for the inherited Save method. But, if self is a CumuloNimbus, the MRO is the one I listed earlier, and it finds Nimbus instead! So, given the use of super in our code now, when we execute cn.Save(), these methods are called:
    CumuloNimbus.Save
    Cumulus.Save
    Nimbus.Save
    Cloud.Save
Problem solved!


[1] I obviously know nothing about the care and handling of dental instruments. Don't ask where that example came from.

[2] Prior to version 2.2, which began the long-awaited fixing of the so-called type-class split, a major wart in Python.

[3] Real Magic™ happening here. Note that the calls to Save invoked through the super-object do not pass self as an argument! And yet, the super function (actually the constructor for a super object) cannot create a bound method, because it doesn't know what method you're going to attempt to call.

"Is that where we are right now? Between the panels?"
–Libby/Boltie

Shot with a big-name cast on a small-time budget, completed in the wake of Kick-Ass (though the films were in production at the same time), Super did not see widespread release until April 2011. Even then, the release wasn't particularly widespread. The film passed faster than a speeding bullet. Many critics savaged the dark comedy about a depressed and disturbed loser who becomes a real-world superhero. Nevertheless, Super soars a little higher than I expected, and earns, at the very least, its cult status. It also has a certain brutal honesty that Kick-Ass lacks.

The story concerns a life-long loser, Frank (Rain Wilson). After his drug-addicted wife leaves him, he decides to become a superhero, applying comic-book conventions and his considerable rage to the real world, with mixed results. When an enthusiastic though deranged young woman becomes his sidekick, they decide to assault the residence of the local criminal with whom the ex-wife now resides.

Bloody violence and dark comedy ensue. Be warned: Super intends to make you uncomfortable, and it often succeeds. Certain portions may prove downright depressing, and you're as likely to wince as laugh at a few of the darker gags.

At other times, you will laugh.

"Why are you wearing a fake beard?"
-a Librarian

The film mercilessly mocks superhero conventions, action movie ethics, and romance tropes. Placed in the real world, vigilante violence results in ugly carnage, simplistic moral crusades bring about injustice, and romantic obsession breeds unhealthy lives. Frank's early forays as the Crimson Bolt, in particular, riff hilariously on the absurdity of the superhero. Those outfits wouldn't conceal your identity from someone who knows you, changing rapidly to your costume in public would prove awkward and embarrassing, and going undercover in disguise, unless you're a professional make-up artist, would simply call attention to the fact that you're wearing a disguise.

Alas, the film's tone and sense of reality, like its moral compass, spin wildly throughout. After mocking the absurdity of its source material, the film begins dealing its own unexplained lapses in reality. Why does no one take down Frank's license plate, despite multiple opportunities? How does Frank afford his house and sizable arsenal on a diner cook's wages? Why are so many people conveniently competent at treating wounds?

And why is Libby, who initially seems relatively well-adjusted, so gung-ho to share in Frank's delusions?

If we see the warped logic that motivates Frank, we never entirely understand what drives the youthful Boltie. Nevertheless, Ellen Page turns in a winning performance as the sociopathic sidekick. From the enthusiasm she brings to violent assault, to the energy she invests in creepy seduction, Page is a key reason to see this movie.

And Page and Wilson aren't the only names of note. Super boasts a stellar cast, and they all give strong performances. It's some strange testimony either to Gunn's script or his persuasive powers that Wilson, Page, Kevin Bacon, Liv Tyler, Nathan Fillion, and Linda Cardellini all signed on. Fillion makes what amounts to a cameo, but his fans will appreciate his brief appearances as the Holy Avenger, an evangelical creation who inspires Frank's warped crusade.

This film also features surprisingly strong effects. Frank's disturbed visions look great. At other times, deliberately cartoony graphics clash with horrific violence. And make no mistake: we're looking at old-school grindhouse gore, grotesquely rendered.

"Do you really think that killing me, stabbing me to death is going to change the world?"
--Jacques

Ambiguous ending notwithstanding, this film doesn't really buy into vigilante ethics the way Kick-Ass, in the end, does. It's more honest than that film, but not nearly so entertaining-- nor as clever as it sets out to be.

Directed by and written by James Gunn.

Rain Wilson as Frank D'Arbo/The Crimson Bolt
Ellen Page as Libby/Boltie
Liv Tyler as Sarah Helgeland
Kevin Bacon as Jacques
Andre Royo as Hamilton
Nathan Fillion as The Holy Avenger
Gregg Henry as Detective Felkner
Don Mac as Range
Linda Cardellini as Pet Store Woman




Epilogue: Radical Interpretation-- with Spoilers.



An interesting interpretation, though one not particularly encouraged by the film nor (that I can find) suggested elsewhere, accounts for some of the plot problems. Consider the rising number of implausibilities as the film progresses, in contrast to the comparatively realistic (if bizarre) earlier scenes. Consider how easily Frank acquires a sidekick, avoids detection, and draws no consequences for significant carnage, before slipping back into his earlier life—right down to the pet bunny. One might imagine that the beginning and ending are "real" in the world of the film, that Sarah leaves him, that he somehow draws her away from her drug addiction (if she ever fell back into it. Maybe she just left him), and that he maintains some distant part in her life. However, the superhero sequences consist of a fantasy he spins about how these events came about. (We'll put aside discussions of metafiction and the fact that, strictly speaking, nothing in the film is real). I see a number of difficulties with this interpretation, but it does resolve some problems.





Su"per, n.

A contraction of Supernumerary, in sense 2.

[Theatrical Cant]

 

© Webster 1913.

Log in or register to write something here or to contact authors.