A Cappuccino project has always needed to have a flat file structure to
be able to compile from source in the web browser.
A new dictionary can be added to the project's Info.plist with the key
'CPFileTranslationDictionary'. It should contain all the path
translations in the project to allow the Browser to find out where in
the file structure the source files are. Check in the AppKit framework
for an example.
Also, a include list can be added in the Info.plist for the key
'CPCompileIncludeFileArray'. The file in the list will be included
by a '#include' statement for each file that is compiled in this project
A last new feature is to add macros in the 'OBJJ_COMPILER_FLAGS' global
variable. It is usually declared in the index.html file. It is done
with the format '-Dmacroname[=macrodefinition]'.
An updated Info.plist file in the AppKit framework will allow the AppKit
to compile from the source in the web browser. The following things is
needed to get this to work:
1. Replace the AppKit folder in your project's Frameworks folder with a
copy of the AppKit folder from the Cappuccino project.
2. Add a copy of the built Aristo2.blend folder to the AppKit's Resource
folder.
3. Add "-DPLATFORM_DOM", "-DPLATFORM_BROWSER" and optionally "-DDEBUG"
to the global variable 'OBJJ_COMPILER_FLAGS' in the project's index.html
file.
The app load time will increase (about 3 seconds on a 2018 MacBook Pro)
as the AppKit framework is compiled from source.
The Foundation framework is not yet tested but it might be working by
adding info about the file structure in the Info.plist file.
The compiler will crash for really large Objective-J files as the array with code segments will hit this limit.
The solution is to append the array segment by segment.
This new warning adds a lot of warnings in the Cappuccino frameworks. I have turned off
the warning in the Jakefiles when compiling most of the Cappuccino frameworks. But it is
on as default for any user projects.
So there is also a new feature to turn off/on warnings as a compiler flag.
These flags are (all flags are on as default):
-Wunused-but-set-variable Warning when a local variable is never read.
-Wshadow-ivar Warning when a local variable is shadowing an instance variable for the class.
-Wcreate-global-inside-function-or-method Warning when creating a global variable inside a function or method.
-Wunknown-class-or-global Warning when a class or global variable is not known.
-Wunknown-ivar-type Warning when the type for an instance variable is not known.
To turn off a flag add a 'no-' prefix. Example: -Wno-unused-but-set-variable
For an example how to use it in a Jakefile please look at the Jakefiles in this commit.
The msgSend function has always returned nil if the receiver has been nil or undefined.
Example:
var a = undefined;
var b = [a someSelector]; // b = nil
The variable b is now nil.
This pull request adds the ability for the msgSend function to return undefined if the receiver is undefined. If the receiver is nil it still return nil.
The above example again:
var a = undefined;
var b = [a someSelector]; // b = undefined
The variable b is now undefined.
Background.
The use of nil in Objective-C corresponds to the use of null in C and C++ and stands for "no value". A fundamental function in Objective-C is when you send a message to a receiver that is nil the result is again a nil value. This can be very convenient as you don't need the check if a receiver is nil before sending a message to it.
Objective-J adds the ability the use class structures and message send functionality for Javascript in the same way as Objective-C adds this to C and C++. Javascript also has the value null and is handled in the same way for Objective-J. Javascript also has the value undefined that stands for "not yet defined". This can sometimes be confusing and many try to handle null and undefined as the same thing. This is almost what Objective-J and the Cappuccino frameworks always has been doing. They try to always check for both null and ``undefined and always return nil but never undefined. We can say that Objective-J understands undefined but will try to translate it to nil.
Why do we need this change.
Javascript has both null and undefined and Objective-J is a superset of Javascript. It is now very hard to use undefined in Objective-J code as it will always try to translate it to nil. There are some Javascript libraries that use both null and undefined values and they are very hard to use from Objective-J programs today. Same if you decide to use nil and undefined as a value in your own Objective-J code. This small change will make undefined a full member of the Objective-J language. It should be as it is a superset of Javascript. The Cappuccino frameworks will still handle undefined but only return nil.
How will it impact.
Today most methods will never return undefined so this is a very limited problem. If any does this the main concern is if some code will only check for nil and not undefined.
Example:
var a = [someObject someSelector];
If (a === nil) a = 42;
...
If the variable someObject contains undefined the variable a will now be set to undefined instead of nil. But the variable a will then never be set to 42.
The correct way is to check for both nil and undefined like this:
var a = [someObject someSelector];
If (a == nil) a = 42;
...
To mimic Objective-C correctly the +initialize method should not be sent on a class hierarchy if it does not implement it.
Also the +initialize method should not allowed to be forwarded to another target with Invocation or any other forwarding mechanism.
Added test cases for this and cleaned up some test cases that succeeded for the wrong reason.
This change will not affect many projects as all classes inherit from CPObject.
The xml parser in the Node.js engine is more modern and can handle more cases. Our property list parser does not handle this. This fix makes the test cases for the property lists run on the Node.js engine.
This allows us to inline the message send function in DEBUG mode. This is great when stepping into a method in the debugger as the message send function is not a separate function. Also the stack traces in the debugger is much more compact as the message send function is not there.
To add source maps add the ”-S” flag to the Jake file when compiling from command line. In the browser you need to add the compiler option into your index.html file. It should look something like this:
OBJJ_COMPILER_FLAGS = [... , "SourceMap"];
All browsers has support for source maps but currently Chrome works best.
David Richardson
daboe01andGitHub
Martin Carlberg
Alfred Wärnsäter
cacaodevandGitHub
Alfred Wärnsäter