What's the easiest way to add a quote box to mediawiki?

Question

When assigning a function to a variable, why does the compiler require a perfect function signature match when...

• The variable's type is a function whose parameter or return is a specific interface, and
• The function being assigned requires a different interface, but is an interface that embeds the expected interface.

Take this example where...

• Fooer is an interface
• FooerBarer is an interface that embeds the Fooer interface
• *bar implements FooerBarer

http://play.golang.org/p/8NyTipiQak

    // Define a type that is a function that returns a Fooer interface
type FMaker func() Fooer

/* Define values of the FMaker type */

    // This works, because the signature matches the FMaker type
var fmake FMaker = func() Fooer {
    return &bar{}
}

    // This causes an error even though a FooerBarer is a Fooer
var fmake2 FMaker = func() FooerBarer {
    return &bar{}
}

So my question is not about an alternate solution, but rather why the compiler is built this way.

It would seem that the compiler would see that by returning a FooerBarer, you are therefore returning a Fooer, and would accept the assignment.

So...

• What is the reason for this strict behavior of the compiler?
• What problem is being solved or danger is being avoided?
• Why is this any different than the compiler accepting a FooerBarer value in an assignment to a Fooer variable?

Solution 1

I made a template in my wiki called Template:quote, which contains the following content:

<div style="background-color: #ddf5eb; border-style: dotted;">
{{{1}}}
</div>

Then I can use the template in a page, e.g.,

{{quote|a little test}}

Works pretty well - Thanks!

Solution 2

<blockquote style="background-color: lightgrey; border: solid thin grey;">
Det er jeg som kjenner hemmeligheten din. Ikke et pip, gutten min.
</blockquote>

The blockquotes are better than divs because they "explain" that the text is actually a blockqoute, and not "just-some-text". Also a blockquote will most likely be properly indented, and actually look like a blockqoute.

Solution 3

To combine the two mostly valid answers, you should use a MediaWiki template that itself utilizes a blockquote.

The content of the template:

<blockquote style="color: lightgrey; border: solid thin gray;">
    {{{1}}}
</blockquote>

Usage on your WIKI page (assuming you named the template "quote"):

{{ quote | The text you want to quote }}

Solution 4

I used the code from @steve k Changing light-grey to black and adding padding between the border and text. I found the light-grey nearly invisible and the text was directly adjacent to the border.

<blockquote style="
 color: black;
 border: solid thin gray;
 padding-top: 10px;
 padding-right: 10px;
 padding-bottom: 10px;
 padding-left: 10px;
 ">
{{{1}}}
</blockquote>

Solution 5

Mediawiki supports the div tag. Combine the div tag with some styles:

<div style="background-color: cyan; border-style: dashed;">
A bunch of text that will wrap.
</div>

You can play around with whatever css attributes you want, but that should get you started.

View more solutions

Comments

[paulsm4]

Many would argue "strict interfaces are Good". That's the whole point of programming a strongly typed language, isn't it? I guess everybody else codes in Perl or Javascript ;)

[I Hate Lazy]

@paulsm4: And I certainly don't disagree with that (I don't know enough yet to disagree ;-) ). But with respect to interfaces, having that "as long as you can do X, Y and Z, we're cool" sort of vibe, I would have expected the compiler to see a fulfilment.

[I Hate Lazy]

Thanks for the answer. I'm trying to correctly understand your first paragraph. Are you saying it has something to do with having a predictable memory layout, which provides the fastest lookup at runtime? If not for some benefit like that, I wouldn't understand why it would make a difference, since the compiler would have at least guaranteed that the value being returned has at least the methods required of a Fooer.

[Stephen Weinberg]

Yes, for any given interface, the itable is in the same order. So if you want Foo(), it is the first method of the itable and a certain offset from the data pointed to in the interface header. In FooerBarer, the first one may be Bar() and the second one Foo().

[I Hate Lazy]

Alright, thanks again. Much of this is foreign concept to me. Any chance you have recommended reading that describes these underlying implementation details in Go or in general? Or is it the sort of thing that can only be gleaned from reading source code?

[zzzz]

"A Fooer is guaranteed to have the first method in the itable be Foo() Fooer." Guaranteed??? Perhaps only guaranteed BS. There's no "itable" ever mentioned in the specs.

[Daniel Heath]

You say "In Go, no assignment has an automatic conversion". However, this is not the case. You can assign a FooerBarer to a Fooer without a (syntactic) cast. You can't, however, assign a func() FooerBarer to a func() Fooer.