added :camelCase() and a note about it being experimental

init.lua

@@ -55,9 +55,9 @@ end
 
 --easy export globally if required
 function _batteries:export()
-	--export all key strings globally, if doesn't always exist
+	--export all key strings globally, if doesn't already exist
 	for k, v in pairs(self) do
-		if not _G[k] then
+		if _G[k] == nil then
 			_G[k] = v
 		end
 	end
@@ -83,4 +83,44 @@ function _batteries:export()
 	return self
 end
 
+
+--convert naming, for picky eaters
+--experimental, let me know how it goes
+function _batteries:camelCase()
+	--convert something_like_this to somethingLikeThis
+	local function snake_to_camel(s)
+		local chunks = _batteries.sequence(_batteries.stringx.split(s, "_"))
+		local first = chunks:shift()
+		chunks:remap(function(v)
+			local head = v:sub(1,1)
+			local tail = v:sub(2)
+			return head:upper() .. tail
+		end)
+		chunks:unshift(first)
+		return chunks:concat("")
+	end
+	--convert all named properties
+	--(keep the old ones around as well)
+	for k, v in pairs(self) do
+		if
+			--only convert string properties
+			type(k) == "string"
+			--ignore private and metamethod properties
+			and not _batteries.stringx.starts_with(k, "_")
+		then
+			--convert and assign
+			local camel = snake_to_camel(k)
+			if k ~= camel and self[camel] == nil then
+				self[camel] = v
+			end
+			--recursively convert anything nested as well
+			if type(v) == "table" then
+				_batteries.camelCase(v)
+			end
+		end
+	end
+
+	return self
+end
+
 return _batteries

readme.md

@@ -135,9 +135,9 @@ I'd strongly recommend that if you find yourself frustrated with the above, stop
 
 ## Git Submodule or Static Install?
 
-`batteries` is fairly easily used as a git submodule - this is how I use it in my own projects, because updating is just a `git pull`.
+`batteries` is fairly easily used as a git submodule - this is how I use it in my own projects, because updating is as quick and easy as a `git pull`, and it's easy to roll back changes if needed, and to contribute changes back upstream.
 
-A static install is harder to update, but easier to trim down if you only need some of the functionality provided. It can also _never_ mysteriously break when updating, which might be appealing to those who just cant help themselves from using the latest and greatest.
+A static install is harder to update, but easier to trim down if you only need some of the functionality provided. It can also _never_ mysteriously break when updating, which might be appealing to those who just cant stop themselves using the latest and greatest.
 
 ## Stripping down `batteries`
 
@@ -147,7 +147,7 @@ Many of them depend on `class`, which can be included alongside pretty easily.
 
 There are some other inter-dependencies in the larger modules, which should be straightforward to detect and figure out the best course of action (include or strip out) if you want to make a stripped-down version for distribution.
 
-Currently the lib is 30kb or so compressed, including this readme, so do think carefully whether you really need to worry!
+Currently (july 2021) the lib is 40kb or so compressed, including this readme, so do think carefully whether you really need to worry!
 
 ## Versioning?
 
@@ -159,7 +159,9 @@ If there is a large enough user base in the future to make a versioning scheme +
 
 ## snake_case? Why?
 
-I personally prefer it, but I accept that it's a matter of taste and puts people off. I'm considering an automatic camelCase API conversion that you can opt in to, this will be updated if that eventuates.
+I personally prefer it, but I accept that it's a matter of taste and puts people off.
+
+I've implemented experimental automatic lowerCamelCase API conversion that you can opt in to by calling camelCase() before export(), let me know if you use it and encounter any issues.
 
 # License