YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

ES6 Styled Import/Export Statements.
KPhillis
#1 Posted : Tuesday, June 20, 2017 3:17:57 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 6/19/2017(UTC)
Posts: 4
Location: USA

Thanks: 1 times
Was thanked: 0 time(s) in 0 post(s)
I was wondering what people's thoughts are on using ECMAScript style Module Import/Export System. This seems like a really good idea, and in general the straight forward to implement.

New Lexer Keywords: export, import, from, as.

Example Code (Script Side): (modified from Example squirrel code on Main web page...

Code File 1: Core/Entity.nut
Code:

// file: Core/Entity.nut
class Entity
{    
    constructor(etype,entityname)
    {
        name = entityname;
        type = etype;
    }
                                    
    x = 0;
    y = 0;
    z = 0;
    name = null;
    type = null;
}

function Entity::MoveTo(newx,newy,newz)
{
    x = newx;
    y = newy;
    z = newz;
}

// Place an entry EntityBase in export table, and have it reference the Entity class.
export Entity as EntityBase;


Code File 2: Core/Player.nut
Code:

// file: Core/Player.nut
// Import EntityBase from the export table, and reference it as Entity in the local file.
import EntityBase from 'Entity';
class Player extends EntityBase {
    constructor(entityname)
    {
        base.constructor("Player",entityname)
    }
    function DoDomething()
    {
        ::print("something");
    }
    
}

// Straight Forward Player Export.
// Also note that the semicolon on the Export Statement Is Optional.
export Player


Code File 2: MyMathLibrary:
Code:

// Sample Exports:
export myPI = 3.14159
export const myConstantPI = 3.14159
export function myDegreetoRadeon(value)
{
    return value / 3.14159;
}
export class myVectorClass {
    constructor()
    {
    }
    x = 0;
    y = 0;

}

Code File 3: GameLogic.nut
Code:


// Rename Player Object MyPlayer for local namespace.
// Also, the semicolon at the end of the line for Imports is optional.
import { Player as MyPlayer} from 'Core/Player'

local newplayer = MyPlayer("da playar");

newplayer.MoveTo(100,200,300);    



As a quick note, I know that I did not show Multiple Import/export, but in general the format would be...
Code:

// Multiple Export:
export {object1, object2, ... , objectN};
export {object1 as myobject1, object2 as myobject2, ..., objectN as myObjectN};

// multiple Import:
import {object1, object2, ... , objectN} from MyLibrary;
import {object1 as myobject1, object2 as myobject2, ..., objectN as myObjectN} from MyLibrary;



Binary Modules: To be determined, however I believe that a system similar to what SQRat does may be a good idea.
absence
#2 Posted : Friday, June 23, 2017 12:12:32 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/23/2014(UTC)
Posts: 109
Man
Location: Northern Germany & Lincolnshire, U.K.

Thanks: 1 times
Was thanked: 10 time(s) in 10 post(s)
I don't see any advantage except syntax sugar for people who did not understand the concept of tables. Which is like C/C++ programmers not understanding pointers: bad.

PS: When it comes to binary module import/export, however, one first has to think about the basics at all (Squirrel version, float/double, 32/64Bit, GC on/off, byte order and lots more to think of...)
KPhillis
#3 Posted : Monday, June 26, 2017 3:02:01 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 6/19/2017(UTC)
Posts: 4
Location: USA

Thanks: 1 times
Was thanked: 0 time(s) in 0 post(s)
absence wrote:
I don't see any advantage except syntax sugar for people who did not understand the concept of tables. Which is like C/C++ programmers not understanding pointers: bad.

PS: When it comes to binary module import/export, however, one first has to think about the basics at all (Squirrel version, float/double, 32/64Bit, GC on/off, byte order and lots more to think of...)


The biggest advantage I can think of for using modules is the following elements...


  • Modules are a lot more Intuitive for Object oriented design because each class can have it's own source file.
  • Makes debugging easier, since individual scripts are smaller.
  • Reduces Namespace pollution - This may not sound like much, but it's a big deal since both Scripts, and C/C++ expansions lead to this.


Now as far as binary module Import/Export, I can see the following as an important element...

  • Float/Double - This is not a major issue. The Virtual machine can be modified to enable developers to toggle precision mode on the fly from c/c++.
  • 32/64-bit Platforms - This is not an issue either. The 64-bit platforms can produce 32-bit bytecode, so 32-bit bytecode should be the first choice.
  • Garbage Collection on/off - The only changes that this makes to the bytecode is adding two functions. This is not a big issue since the two functions for garbage collection can be turned into dummy functions when Garbage Collection is turned off.
  • Byte Order - This is a trivial fix. A 32-bit Byte order mark can be used to specify the platforms Byte order setup.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.144 seconds.