I'm using Twitter Bootstrap on a project at the moment, including the LESS files and compiling with some additional LESS code that we've written.
The latest release has meant we need to override some of the Bootstrap LESS variables. One option here was to maintain a modified copy of Bootstrap which we patch on each release.
But I note that it's possible to override a variable defined in an #import LESS file by re-declaring the variable after the import statement.
E.g.:
#import "twitter-bootstrap/bootstrap.less";
// Restore base font size to pre 2.1.1 defaults
#baseFontSize: 13px;
// Add some custom LESS code here
Is this bad practice? Is it an artifact of the way the LESS compiler works, or an intended part of it? I couldn't find much information on this, although I did find the following two references:
Because of a bug in the Less compiler, you can override the “constant” value of a variable by changing it after it is initially declared.
http://rubysource.com/how-to-customize-twitter-bootstrap%E2%80%99s-design-in-a-rails-app
and
Customize the columns and gutters by overriding these three variables (after the grid.less import has been declared).
http://semantic.gs/
The LESS site itself says that variables are 'constants':
http://lesscss.org/
Note that variables in LESS are actually ‘constants’ in that they can only be defined once.
But then I see other sites using this approach.. It's certainly easier than maintaining a vendor branch and seems to work fine with less.js.
Would appreciate any thoughts on whether this is a bad thing to do or not!
Ok! One of the above issues led to a discussion of the intended behaviour, and it turns out that overriding LESS variables is fine.
Your declarations will overwrite each-other in the same scope in CSS; The same is true for LESS.
https://github.com/cloudhead/less.js/issues/297
Like in CSS, overriding within a scope is an intended way to use LESS.
It´s ok!
I usually create a less file with "components" and variables with a default value. Then I import after that a file with same variables but "customers" values, overwritting default ones. In that way i have only to change some values to create a new design for each customer.
It´s ok and very useful.
Related
I prefer working with files that are less than 1000 lines long, so am thinking of breaking up some Erlang modules into more bite-sized pieces.
Is there a way of doing this without expanding the public API of my library?
What I mean is, any time there is a module, any user can do module:func_exported_from_the_module. The only way to really have something be private that I know of is to not export it from any module (and even then holes can be poked).
So if there is technically no way to accomplish what I'm looking for, is there a convention?
For example, there are no private methods in Python classes, but the convention is to use a leading _ in _my_private_method to mark it as private.
I accept that the answer may be, "no, you must have 4K LOC files."
The closest thing to a convention is to use edoc tags, like #private and #hidden.
From the docs:
#hidden
Marks the function so that it will not appear in the
documentation (even if "private" documentation is generated). Useful
for debug/test functions, etc. The content can be used as a comment;
it is ignored by EDoc.
#private
Marks the function as private (i.e., not part of the public
interface), so that it will not appear in the normal documentation.
(If "private" documentation is generated, the function will be
included.) Only useful for exported functions, e.g. entry points for
spawn. (Non-exported functions are always "private".) The content can
be used as a comment; it is ignored by EDoc.
Please note that this answer started as a comment to #legoscia's answer
Different visibilities for different methods is not currently supported.
The current convention, if you want to call it that way, is to have one (or several) 'facade' my_lib.erl module(s) that export the public API of your library/application. Calling any internal module of the library is playing with fire and should be avoided (call them at your own risk).
There are some very nice features in the BEAM VM that rely on being able to call exported functions from any module, such as
Callbacks (funs/anonymous funs), MFA, erlang:apply/3: The calling code does not need to know anything about the library, just that it's something that needs to be called
Behaviours such as gen_server need the previous point to work
Hot reloading: You can upgrade the bytecode of any module without stopping the VM. The code server inside the VM maintains at most two versions of the bytecode for any module, redirecting external calls (those with the Module:) to the most recent version and the internal calls to the current version. That's why you may see some ?MODULE: calls in long-running servers, to be able to upgrade the code
You'd be able to argue that these points'd be available with more fine-grained BEAM-oriented visibility levels, true. But I don't think it would solve anything that's not solved with the facade modules, and it'd complicate other parts of the VM/code a great deal.
Bonus
Something similar applies to records and opaque types, records only exist at compile time, and opaque types only at dialyzer time. Nothing stops you from accessing their internals anywhere, but you'll only find problems if you go that way:
You insert a new field in the record, suddenly, all your {record_name,...} = break
You use a library that returns an opaque_adt(), you know that it's a list and use like so. The library is upgraded to include the size of the list, so now opaque_adt() is a tuple() and chaos ensues
Only those functions that are specified in the -export attribute are visible to other modules i.e "public" functions. All other functions are private. If you have specified -compile(export_all) only then all functions in module are visible outside. It is not recommended to use -compile(export_all).
I don't know of any existing convention for Erlang, but why not adopt the Python convention? Let's say that "library-private" functions are prefixed with an underscore. You'll need to quote function names with single quotes for that to work:
-module(bar).
-export(['_my_private_function'/0]).
'_my_private_function'() ->
foo.
Then you can call it as:
> bar:'_my_private_function'().
foo
To me, that communicates clearly that I shouldn't be calling that function unless I know what I'm doing. (and probably not even then)
Do I really have to use the ClassImp macro to benefit the automatic dictionary and streamer generation in ROOT? Some online tutorials and examples mention it but I noticed that simply adding the ClassDef(MyClass, <ver>) macro to MyClass.h and processing it with rootcint/rootcling already generates most of such code.
I did look at Rtypes.h where these macros are defined but to follow preprocessor macros calling each other is not easy and so, it would be nice if experts could confirm the role of ClassImp. I am specifically interested in recent versions of ROOT >= 5.34
Here is the answer I got on roottalk mailing list confirming that the usage of ClassImp is essentially outdated.
ClassImp is used to register in the TClass the name of the source file
for the class. This was used in particular by THtml (which has now
been deprecated in favor of Doxygen). So unless you code/framework
needs to know the name of the source files, it is no longer necessary
to have ClassImp.
ClassDef is necessary for class inheriting from TObject (or from any
classes that has a ClassDef). In the other cases, it provide
accelerator that makes the I/O slightly faster (and thus is
technically not compulsory in this case). It also assign a version
number to the schema layout which simplifies writing schema evolution
rules (on the other hand, there is other alternative to assign a
version number to the schema layout).
What exactly are you trying to do? The ClassImp and ClassDef macros add members to the class that provide Run-Time Type Information and allow the class to be written to root files. If you are not interested in that, then don't bother with these macros.
I never use them.
I'm rolling out my own bootstrap-sass customization in a pretty big project. In my git repo I have my own application.scss file which mirrors the original bootstrap.scss, removing what I don't need and adding my own custom variables, mixins and styles.
I cannot understand the right way to do this while retaining a DRY approach. Should I #import 'application/variables'; before or after I #import 'path/to/bootstrap/variables';?
The before approach
This seems to be the preferred way for bootstrap developers, because all the variables declared in _variables.scss are followed by the !default flag, which takes action only if the variable has been previously declared.
Where does this fail? Take for example a declaration like this:
$brand-primary: $gray;
Compiling this SASS code will spit out an undeclared variable error, because $gray is defined in bootstrap's _variables.scss, which is imported later. If I want this to work, I'll have to re-declare $gray at the top of my file, even though it didn't change from the default.
This may not sound like a big deal, but over a certain level of complexity it starts to happen quite a lot, and your application/_variables.scss goes from being "the file where I define my own variables" to "the file where I define my variables and copy over some other bootstrap stuff without actually changing it".
The after approach
To overcome the problem of the before approach I tried to import my variables after bootstrap's ones. It turns out it doesn't really work either, and it's broken in subtler ways. Look at this example:
$padding-base-vertical: 8px;
Looks innocent, right? And in fact it will change the vertical padding as needed. How does this break? It breaks, for example, the $input-height-base variable, declared later in bootstrap's _variables.scss, which is not correctly recalculated based on $padding-base-vertical's changes.
And this is how $input-height-base is defined:
$input-height-base: ($line-height-computed + ($padding-base-vertical * 2) + 2) !default;
Thus $input-height-base is calculated with $padding-base-vertical's default value and then never again. As a side effect, this kind of problem is quite hard to debug (at least it was for me).
The "solution"? Redeclare $input-height-base and all the other dependent variables in application/_variables.scss just like they are in bootstrap. Yes, it's the same workaround of the after approach.
So, is there a DRY way to do this? I can't even split my variables in two, part to set before and part to set after, because I could bump in a variable which hits both problems.
The first approach is the less ugly, but it's far from being an ideal solution.
This problem took me some time to puzzle out as well. Here's the solution I came up with.
To keep your SASS code modular, keep distinct separation between the two types of code - declarative and imperative. By declarative code I mean definitions of variables, functions, and mixins. By imperative code I mean style definitions (any code that will actually produce some output when compiled). Keep those kinds of code in separate files. You can then transparently declare dependencies (#imports) between files containing declarative code, because including declarative code multiple times will have no effect on the output.
Using the approach outlined above, split your "customized Bootstrap" into two files - bootstrap-declarations and bootstrap-styles (I actually split it into more files to keep variables separate from functions/mixins). Then #import the bootstrap-declarations from your application's variables without any hassle and declare your variables both before and after the #import as needed. In your application's imperative code (styles), #import your application's variables as the very first thing, before #import of bootstrap-styles, and you're all set.
So I am using the new #import module syntax introduced with the latest Xcode - I still wonder where the best place is to put them. Before, I would place library imports and very important categories in the .pch file, but now that's not necessary anymore (at least not for the native frameworks). My first idea was to create a modules.h file and do all the imports there, then include that modules.h file in the AppDelegate - but this doesn't seem right. Also, importing in the first place you need it doesn't make sense either, since you might use it in different places.
This is in fact a question about "best practices" which is - of course - a little subjective. But I think this affects a lot of people and the overall project structure. So please share your solution to this.
it sounds like you weren't doing it the best way before, In general you want as few symbols available at any one time. For a few different reasons:
less likely to make a mistake with symbols that have the same name but different values, or types... and for reasons that the compiler has to import less crap into each compilation unit.
I am not an expert on how #import has changed the compiler semantics of preprocessing and compiling, but I suspect you should still basically import things as close to the point that they will be used as possible.
I generally will not generally import any class's headers into another class's .h file.
in a .h I will forward declare any classes with #class SomeCLass and only include enough headers to satisfy the c/c++ types that I use as ivar/properties. The only exception to that being if I need to include a superclass's header or another .h for a protocol.
the rest of the includes go into the .m
I like to keep my pch pretty spartan, but if you have some utility categories or a widely used library you could include stuff in there, I tend not to... but in a smaller project you probably wont run into problems... you will run into indexing problems in projects with hundreds of source files, especially if you have some Objective-C++ units. That will end up hurting code completion and live syntax checking.
I am getting sick of seeing the warning
"Declaration of 'index' shadows a global declaration"
index is defined in string.h. I don't think that it's required for anything I am using and I really don't want to change all the local vars from index to something else.
Anyone know of a way to find out how (by what path) string.h is included? Is it possible to prevent it from being included?
The index function is actually declared in /usr/include/strings.h, and is marked as removed as of POSIX issue 7. You can hide its declaration by setting the appropriate POSIX version with the compiler flag -D_POSIX_C_SOURCE=200809. This will also hide other functions deprecated in issue 7, like bcopy and bzero.
I find -Wshadow extremely annoying and rarely useful. Even if you solve this one case, there are bound to be others in the future, especially since system headers may define non-standard functions and variables which yours unintentionally shadow.
Personally, I would just disable the warning, and manually make sure no variables, functions, etc. are named the same as something being used.