Asking on here as opposed to repo as per contributing.md.
I noticed that on most elements .mdl-layout__obfuscator for example an .is-visible class is added to make this object visible.
I was curious as to why you do not use a modifier to achieve this i.e:
.mdl-layout__obfuscator .mdl-layout__obfuscator--visible
Is there any particular reason for this?
Cheers.
Because state-classes are intended for elements, what can change his state. Those can have or not have this „--visible“ modifier.
See example to feel the difference between modifier and state class: http://www.sassmeister.com/gist/91bebd16ce4bbb7d6a45
Btw, canonical BEM doesn't have state classes, but some BEM realizations like SMACSS or Harry Robert's BEMIT — does. MDL is also a one of the BEM realizations, so you should not thinking about it like a mandatory rule.
Related
I'd like to choose class of an element bases on importance:
<strong> Importance:
<span :class="importance ? (calculate class here)">
</span> {{someText}}
</strong>
Let's say the class vlue should be imp0 ,imp1,imp2, imp3 or imp4, depending on whether importance equals 0,1,2,3 or 4.
You may ask why not calculate the value in a method function?
The answer is: to keep the class value synced with the result of a separate method which also gets importance as input parameter after the class is rendered.
So wondering how can I achieve this?
Update: I managed to do it with a convulted ternary conditional:
:class="importance==0 ? 'imp0': (importance==1? 'imp1': (importance==2 ? 'imp2': (importance==3 ? 'imp3': 'imp4')))
but wondering if there is a more clean way to do so?
If your mapping is that direct, you can let it go with simple expression:
:class="'imp' + importance"
... but I strongly advise you to at least consider it a technical debt. Remember, you can use any attribute in your CSS selector, not just classes.
I am adding an element into a MutableList and I want to know its index.
mutableList.add(foo)
Will the index of the most recently added element always be the last index mutableList.size - 1 like it is with ArrayList?
I don't want to use mutableList.indexOf(foo) because I believe it takes O(n). I'm not finding lot of documentation on these.
Yes, MutableList.add() always adds to the end of the list (this is a requirement for any class implementing the interface). I've filed an issue to say this explicitly in the documentation.
MutableList is merely an interface. How are you initializing the list?
Using Kotlin methods like mutableListOf() creates ArrayList objects by default.
You raise a question that has never occurred to me since from testing and experience I've found that all new elements added with the add method are placed at the end.
I believe that this is the case and won't change.
Although not mentioned in the documentation, this case holds. If it didn't then for sure it would be in the documentation. Just like Set where it says
A generic unordered collection
On JVM, MutableList is equivalent to java.util.List whose add documentation does specify
Appends the specified element to the end of this list
It's not obvious to me from reading the current API design guideline, which of the following version is better.
class MediaLoader {}
class MediaRequest {}
let mediaLoader = MediaLoader()
let mediaRequest = MediaRequest()
// Option 1
mediaLoader.add(request: mediaRequest)
// Option 2
mediaLoader.add(mediaRequest: mediaRequest)
// Option 3
mediaLoader.addRequest(mediaRequest)
// Option 4
mediaLoader.add(mediaRequest)
Which of the above conforms to the current API design guideline the best?
The answer really depends on the purpose and semantics of MediaLoader. If MediaLoader is only a collection of mediaRequests, then .add(mediaRequest) is the way to go because it would flow grammatically and be meaningful in context.
On the other hand, if a mediaRequest is merely one of many different things contributing to its purpose, then .add() alone would not convey enough context to properly read the statement. For example, if you could also add display channels or filters, then merely saying .add(something) would not be clear enough. This is when you would use an extended name that describes the relationship. e.g. .addRequest(), addChannel(), addFilter().
But not .add(request:...), because, using a name for the first parameter is not the ideal way to distinguish between relationships. It should be used instead to clarify the method by which the addition will be performed or the way the request will be accessed. This will leave the "nameless" variant for the most frequent and straightforward use case. e.g. .add(fromTemplate:webRequesTemplate) or .addRequest(fromTemplate:webTemplate).
For example: Meta-information
metaInfornation, metainformation or metainfo?
getMetainfo, getMetaInfo or getMetaInformation?
what about objective-c style?
I am personally a fan of camelCase and no abbreviations. So I would use metaInformation. metaInfo is also good because it's a very common abbreviation.
What I dislike is something like printAttr or similar.
Apple has docs on that topic describing the conventions.
Note that you should not use get in your getter!
When you apply these conventions you have many opportunities (e.g. Key-Value-Coding).
If it's a property, then you'd want to use metaInformation or metaInfo, and it will generate the getter as -metaInformation or -metaInfo. Never use get in a method name.
Using online dictionary tools doesn't really help. I think the way encapsulate is use in computer science doesn't exactly match its meaning in plain English.
What is the antonym of computer science's version of encaspulate? More specifically, what is an antonym for encapsulate that would work as a function name.
Why should I care? Here's my motivation:
// A class with a private member variable;
class Private
{
public:
// Test will be able to access Private's private members;
class Test;
private:
int i;
}
// Make Test exactly like Private
class Private::Test : public Private
{
public:
// Make Private's copy of i available publicly in Test
using Private::i;
};
// A convenience function to quickly break encapsulation on a class to be tested.
// I don't have good name for what it does
Private::Test& foo( Private& p )
{ return *reinterpret_cast<Private::Test*>(&p); } // power cast
void unit_test()
{
Private p;
// using the function quickly grab access to p's internals.
// obviously it would be evil to use this anywhere except in unit tests.
assert( foo(p).i == 42 );
}
The antonym is "C".
Ok, just kidding. (Sort of.)
The best terms I can come up with are "expose" and "violate".
The purpose behind encapsulation is to hide/cover/protect. The antonym would be reveal/expose/make public.
How about Decapsulation..
Though it aint a computer science term, but in medical science, Surgical removal of a capsule or enveloping membrane.. Check out here..
"Removing/Breaking encapsulation" is about the closest thing I've seen, honestly.
If you think of the word in the English sense, to encapsulate means to enclose within something. But in the CS sense, there's this concept of protection levels and it looks like you want to imply circumventing the access levels as well, so something like "extraction" doesn't really convey the meaning you're looking for.
But if you just think of it in terms of what the access levels are, it looks like you're making something public so, how about "publicizing"?
This is not such a simple question - Scott Meyers had an interesting article to demonstrate some of the nuances around encapsulation here.
I'll start with the punchline: If
you're writing a function that can be
implemented as either a member or as a
non-friend non-member, you should
prefer to implement it as a non-member
function. That decision increases
class encapsulation. When you think
encapsulation, you should think
non-member functions.
How about "Bad Idea"?
The true antonym of "Encapsulation" is "Global State".
The general opposite of encapsulation is coupling and we often talk about systems that are tightly coupled or loosely coupled.
The reason you'd want components to be encapsulated is because it makes it easier to reason about how they work.
Take the analogy of trains: the consequence of coupling the railcars is that the driver must consider the characteristics (inertia, length) of the entire train.
Obviously, though, we couple systems because we need them to work together.
Inverted encapsulation and data structures
There's another term that I've been digging for, which is how I came across this question, that refers to a non-standard style of data structures.
The standard style of encapsulation is exemplified by Java's LinkedList; the actual nodes of the list are designed to be inaccessible to the consumer. The theory is that this is an implementation detail and can change to improve performance, while existing code will continue to run.
Another style is the classic functional cons-list. This is a singly linked list, and the idea is that it's so simple that there's nothing to improve about the data structure, e.g.
data [a] = [] | a : [a] deriving (Eq, Ord)
-- Haskellers then work directly with the list
-- There's nothing to hide because it's so simple
typicalHaskell :: [a] -> b
typicalHaskell [] = emptyValue
typicalHaskell h : t = h `doAThing` (typicalHaskell t)
That's the definition from Haskell's standard prelude though the report notes that isn't valid Haskell syntax, and in practice [a] is defined in the guts of the compiler.
Then there's what I'm calling an "inverted" data structure, but I'm still looking for the correct term. This is, I think, really the opposite of encapsulation.
A good example of this is Python's heapq module. The data structure here is a binary heap, but there isn't a Heap class. Rather, you get a collection of functions that operate on generic Python lists and you're responsible for using those methods correctly to ensure the heap invariants are maintained.
How about "spaghetti"?