1. Euphoria vs. C and OOP

People have been saying that Euphoria should be more "C" like, or
  more "OOP" like.  Euphoria has unique features that set it apart from
  C or OOP, and make it flexible, but in different ways.

  Instead of trying to make Euphoria fit into a C mold or OOP mold,
  take advantage of the unique features of Euphoria.

  sequences are structures, but not like C.  They are just as flexible,
  perhaps even more so, since it is easier to add to or change what
  a sequence is.

  A sequence can be just a string, "ABC", or a structure:
a = {
       "ABC",            -- string
       123,              -- integer or atom
       {"XYZ", 456}      -- another sequence
      }

   Referencing these members can be done with constants, like

constant NAME  = 1, AMT  = 2, DESC = 3,
            DNAME = 1, DAMT = 2

   a[NAME]           ("ABC")

   or
   a[DESC]           (  {"XYZ", 456}  )
   a[DESC][DNAME]    ("XYZ")
   a[DESC][DAMT]     (456)


   C has Public and Private functions.  Euphoria can have them too,
   but in different ways.

   See the following include and program to see what I mean.  I hope
   this can stimulate some discussion as to using Euphoria in a more
   structured way.


  ====================================================================
  ==  Member banking.e                                              ==
  ====================================================================
  --*----------------------------------------------------------------*
  --*  banking.e             bank account program                    *
  --*                                                                *
  --*    Public                                                      *
  --*      function  BankProgram                                     *
  --*                                                                *
  --*    Private (or member functions)                               *
  --*      function  CreateAcct                                      *
  --*      function  Withdrawal                                      *
  --*      function  Deposit                                         *
  --*      procedure Balance                                         *
  --*                                                                *
  --*  example of account:                                           *
  --*                                                                *
  --*  a = {015505, "John Smith", 12000.15}                          *
  --*  a[1] = acctno                                                 *
  --*  a[2] = acctname                                               *
  --*  a[3] = balance                                                *
  --*----------------------------------------------------------------*

global constant
    acctno   = 1,
    acctname = 2,
    balance  = 3,
    blank_acct = {0, "", 0}

function CreateAcct()               -- Private function returns account
  sequence User_account

  User_account           = blank_acct
  User_account[acctno]   = 111000              -- assign next account #
  User_account[acctname] = prompt_string("Enter name : ")

  return User_account

end function

function Withdrawal(sequence account, atom amount)  -- Private function
  account[balance] -= amount

  return account

end function

function Deposit(sequence account, atom amount)    -- Private function
  account[balance] += amount

  return account

end function

procedure Balance(sequence account)                -- Private procedure
  printf(1, "account : %d  %s  Balance : %.2f\n", {account[acctno],
                                                   account[acctname],
                                                   account[balance]})

end procedure

global function BankProgram(sequence parms)
  --*----------------------------------------------------------------*
  --*  Public because it is global                                   *
  --*----------------------------------------------------------------*

  sequence command, User_account, ret_account
  atom amount

  --*----------------------------------------------------------------*
  --*  parms[1] = command                                            *
  --*  parms[2] = account (optional when creating new account)       *
  --*  parms[3] = optional amount                                    *
  --*  parms[4]... optional and expandable                           *
  --*----------------------------------------------------------------*

  command  = parms[1]

  if    equal(command, "new") then
    ret_account  = CreateAcct()
  elsif equal(command, "Balance") then
    User_account = parms[2]
    Balance(User_account)
    ret_account  = {}
  elsif equal(command, "Deposit") then
    User_account = parms[2]
    amount       = parms[3]
    ret_account  = Deposit(User_account, amount)
  elsif equal(command, "Withdrawal") then
    User_account = parms[2]
    amount       = parms[3]
    ret_account  = Withdrawal(User_account, amount)
  else
    puts(1, "Unknown command\n")
    return {}
  end if

  return ret_account

end function


  ====================================================================
  ==  end of Member banking.e                                       ==
  ====================================================================




  ====================================================================
  ==                main program:                                   ==
  ====================================================================
  include get.e
  include graphics.e
  include banking.e

  sequence myAccount, null_status

  text_color(WHITE) bk_color(BLUE)
  clear_screen()

  myAccount   = BankProgram({"new"})
  myAccount   = BankProgram({"Deposit",    myAccount, 12000.00})
  myAccount   = BankProgram({"Withdrawal", myAccount, 150.00})
  null_status = BankProgram({"Balance",    myAccount})


  Other functions and features can be added from this basic
  framework.  Features such as checking for overdraft status, adding
  extra fees, crediting or debiting accounts, etc.

new topic     » topic index » view message » categorize

2. Re: Euphoria vs. C and OOP

One of the problems that I see is that when your data structures get past a
certain complexity and your program reaches a certain size, defining all of those
constants gets to be tedious and since they are global they pollute the global
namespace.

That's why I kind of like an enum system and probably a dot notation system as
well, where members of a sequence specified by the dot notation aren't variables
themselves.

Hmm. That's probably not very clear but it is the best I can describe it for
now. I'm sure others will weigh in.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

new topic     » goto parent     » topic index » view message » categorize

3. Re: Euphoria vs. C and OOP

Hi there,


That's something like i did with WinClass, except there are
graphical features included in each 'class', so each class
can have public and private data and functions, and also
public graphical interfaces.


Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

new topic     » goto parent     » topic index » view message » categorize

4. Re: Euphoria vs. C and OOP

I agree with you Bill, Euphoria should stay euphoria, not becoming,
c++,java or whatever of the same.

Your exemple is a good one, but the use of strings for commands would
slow down the execution a bit. Global constants could be defined instead for
commands.

Improvement to euphoria should stick to simple guidelines:
- minimize typing effort
- reduce name conflict (improvement to namespaces)
- reduce scope of variables (related to namespaces)

My yesterday suggestions stick to those guidelines and I agree with Jason
concerning an enum decleration because it would reduce typing in accessing
sequence elements by defining constants.

regards,
Jacques Deschênes

new topic     » goto parent     » topic index » view message » categorize

5. Re: Euphoria vs. C and OOP

jacques deschênes wrote:
> 
> I agree with you Bill, Euphoria should stay euphoria, not becoming,
> c++,java or whatever of the same.
> 
> Your exemple is a good one, but the use of strings for commands would
> slow down the execution a bit. Global constants could be defined instead for
> commands.
> 
> Improvement to euphoria should stick to simple guidelines:
> - minimize typing effort
> - reduce name conflict (improvement to namespaces)
> - reduce scope of variables (related to namespaces)
> 
> My yesterday suggestions stick to those guidelines and I agree with Jason
> concerning an enum decleration because it would reduce typing in accessing
> sequence elements by defining constants.
> 
> regards,
> Jacques Deschênes

So you want to change:

sequence holiday

holiday="christmas" 


to

sequence holiday."christmas"


For the point of saving typing. Is this correct?
Would holiday be changed later by 

holiday="easter"
 Or would another period be needed.

holiday."easter"?

Don Cole

new topic     » goto parent     » topic index » view message » categorize

6. Re: Euphoria vs. C and OOP

Bill Reed wrote:
> 
> 
>   People have been saying that Euphoria should be more "C" like, or
>   more "OOP" like.  Euphoria has unique features that set it apart from
>   C or OOP, and make it flexible, but in different ways.
> 
>   Instead of trying to make Euphoria fit into a C mold or OOP mold,
>   take advantage of the unique features of Euphoria.
> 
>   sequences are structures, but not like C.  They are just as flexible,
>   perhaps even more so, since it is easier to add to or change what
>   a sequence is.
> 
>   A sequence can be just a string, "ABC", or a structure:
> }}}
<eucode>
>   a = {
>        "ABC",            -- string
>        123,              -- integer or atom
>        {"XYZ", 456}      -- another sequence
>       }
> </eucode>
{{{

>    Referencing these members can be done with constants, like
> 
> }}}
<eucode>
>    constant NAME  = 1, AMT  = 2, DESC = 3,
>             DNAME = 1, DAMT = 2
> 
>    a[NAME]           ("ABC")
> 
>    or
>    a[DESC]           (  {"XYZ", 456}  )
>    a[DESC][DNAME]    ("XYZ")
>    a[DESC][DAMT]     (456)
> </eucode>
{{{

> 
>    C has Public and Private functions.  Euphoria can have them too,
>    but in different ways.
> 
>    See the following include and program to see what I mean.  I hope
>    this can stimulate some discussion as to using Euphoria in a more
>    structured way.
> 
> 
>   ====================================================================
>   ==  Member banking.e                                              ==
>   ====================================================================
> }}}
<eucode>
> 
>   --*----------------------------------------------------------------*
>   --*  banking.e             bank account program                    *
>   --*                                                                *
>   --*    Public                                                      *
>   --*      function  BankProgram                                     *
>   --*                                                                *
>   --*    Private (or member functions)                               *
>   --*      function  CreateAcct                                      *
>   --*      function  Withdrawal                                      *
>   --*      function  Deposit                                         *
>   --*      procedure Balance                                         *
>   --*                                                                *
>   --*  example of account:                                           *
>   --*                                                                *
>   --*  a = {015505, "John Smith", 12000.15}                          *
>   --*  a[1] = acctno                                                 *
>   --*  a[2] = acctname                                               *
>   --*  a[3] = balance                                                *
>   --*----------------------------------------------------------------*
> 
> global constant
>     acctno   = 1,
>     acctname = 2,
>     balance  = 3,
>     blank_acct = {0, "", 0}
> 
> function CreateAcct()               -- Private function returns account
>   sequence User_account
> 
>   User_account           = blank_acct
>   User_account[acctno]   = 111000              -- assign next account #
>   User_account[acctname] = prompt_string("Enter name : ")
> 
>   return User_account
> 
> end function
> 
> function Withdrawal(sequence account, atom amount)  -- Private function
>   account[balance] -= amount
> 
>   return account
> 
> end function
> 
> function Deposit(sequence account, atom amount)    -- Private function
>   account[balance] += amount
> 
>   return account
> 
> end function
> 
> procedure Balance(sequence account)                -- Private procedure
>   printf(1, "account : %d  %s  Balance : %.2f\n", {account[acctno],
>                                                    account[acctname],
>                                                    account[balance]})
> 
> end procedure
> 
> global function BankProgram(sequence parms)
>   --*----------------------------------------------------------------*
>   --*  Public because it is global                                   *
>   --*----------------------------------------------------------------*
> 
>   sequence command, User_account, ret_account
>   atom amount
> 
>   --*----------------------------------------------------------------*
>   --*  parms[1] = command                                            *
>   --*  parms[2] = account (optional when creating new account)       *
>   --*  parms[3] = optional amount                                    *
>   --*  parms[4]... optional and expandable                           *
>   --*----------------------------------------------------------------*
> 
>   command  = parms[1]
> 
>   if    equal(command, "new") then
>     ret_account  = CreateAcct()
>   elsif equal(command, "Balance") then
>     User_account = parms[2]
>     Balance(User_account)
>     ret_account  = {}
>   elsif equal(command, "Deposit") then
>     User_account = parms[2]
>     amount       = parms[3]
>     ret_account  = Deposit(User_account, amount)
>   elsif equal(command, "Withdrawal") then
>     User_account = parms[2]
>     amount       = parms[3]
>     ret_account  = Withdrawal(User_account, amount)
>   else
>     puts(1, "Unknown command\n")
>     return {}
>   end if
> 
>   return ret_account
> 
> end function
> </eucode>
{{{

> 
>   ====================================================================
>   ==  end of Member banking.e                                       ==
>   ====================================================================
> 
> 
>   ====================================================================
>   ==                main program:                                   ==
>   ====================================================================
> }}}
<eucode>
> 
>   include get.e
>   include graphics.e
>   include banking.e
> 
>   sequence myAccount, null_status
> 
>   text_color(WHITE) bk_color(BLUE)
>   clear_screen()
> 
>   myAccount   = BankProgram({"new"})
>   myAccount   = BankProgram({"Deposit",    myAccount, 12000.00})
>   myAccount   = BankProgram({"Withdrawal", myAccount, 150.00})
>   null_status = BankProgram({"Balance",    myAccount})
> 
> </eucode>
{{{

> 
>   Other functions and features can be added from this basic
>   framework.  Features such as checking for overdraft status, adding
>   extra fees, crediting or debiting accounts, etc.

This is the sort of hack you are unfortunately saddled with when using the 
language. Removing this sort of global namespace pollution is a priority 
issue IMHO.
If only because, once you have defined a constant "balance" to number the 
relevant field in your sequence, you can no longer have another "structure" 
use the same name, as the field index name must be global. This makes no 
sense.

CChris

new topic     » goto parent     » topic index » view message » categorize

7. Re: Euphoria vs. C and OOP

This is exactly the way we use EU except that all the table column names are
unique. Here's a sample table.

1st 2 letters - system. AR here
2nd 2 lettere - table name 
3rd ? letters - column name

--------------------------------------------------------------------------------
-- include arCustomer.e			         created 03/15/02
-- dbNames= {"ar", "arCustomer"}
-- arcu
-- Key Length: 8
--
--		AR Customer
--
global constant					-- dec(x,y) defined as tot digits,decimal places
    arcuLength	    	= 039,
    arcuCoNbr           = 001, --K1  dec(2,0)      Company Number
    arcuCustNbr         = 002, --K2  dec(6,0)      Customer Number
    arcuCustNm          = 003, --    char(40)      Customer Name
    arcuAddr1           = 004, --    char(25)      Address Line 1
    arcuAddr2           = 005, --    char(25)      Address Line 2
    arcuCity            = 006, --    char(20)      City
    arcuSt              = 007, --    char(2)       State
    arcuZip             = 008, --    char(10)      Zip Code - 9 digit zip code
                               --                  formatted as 99999-9999
arcuPhone           = 009, --    char(17)      Phone - formatted as
    999-999-9999
--                  XXXX where XXXX is an
                               extension.
    arcuContact1Nm      = 010, --    char(30)      Contact 1 Name
    arcuContact2Nm      = 011, --    char(30)      Contact 2 Name
    arcuSlsmnNbr        = 012, --    char(3)       Salesman Number - default
--                  salesman number for the
                               salesman
--                  to receive credit/commission
                               for
                               --                  a sale to the customer.
arcuBillCustNbr     = 013, --    dec(6)        Bill to Customer Number -
    this is
--                  the number of the customer
                               which
--                  will be billed for a sale to
                               the
                               --                  customer.
arcuCustCl          = 014, --    dec(1)       Customer Class - the price
    level
--                  at which to charge the
                               customer.
--                  Values 1 - 6 are for the
                               price
--                  levels in the Order
                               Processing
                               --                  sub-system. Value 6 indicates
                               --                  that the customer should be
                               --                  charged at cost.
    arcuLstInvDt        = 015, --    date          Last Invoice Date
    arcuLstInvAmt       = 016, --    dec(9,2)      Last Invoice Amount
    arcuLstPayDt        = 017, --    date          Last Pay Date
    arcuLstPayAmt       = 018, --    dec(9,2)      Last Pay Amount
    arcuYtdSales        = 019, --    dec(9,2)      Year-to-Date Sales
arcuInvPdCt         = 020, --    dec(6,0)      Invoice Paid Count - the
    number
                               --                  of invoices the customer has
                               --                  paid.
arcuAvgPayDays      = 021, --    dec(4,0)      Average Days to Pay - the
    average
                               --                  number of days it takes the
                               --                  customer to pay an invoice.
    arcuCurrBal         = 022, --    dec(9,2)      Current Balance
arcuStmtFl          = 023, --    char(1)       Statements Flag - indicates
    if
                               --                  the customer is to receive
                               --                  statements. Y = yes, N = no
arcuTaxAuthCd       = 024, --    char(5)       Tax Authority Code - valid
    codes
                               --                  are in the arCode and opCode
                               --                  tables.
arcuFinanceChg      = 025, --    char(1)       Finance Charge Flag -
    indicates
--                  if the customer should be
                               charged
--                  a finance charge for an over
                               due
                               --                  balance. Y = yes, N = no
arcuCustCatCd       = 026, --    char(2)       Customer Category Code - a
    user
                               --                  assigned value to indicate
                               --                  location, zone, etc.
arcuCrLimit         = 027, --    dec(9,2)      Credit Limit - the maximum
    amount
                               --                  of a sale allowed for the
                               --                  customer.
    arcuLstYrSales      = 028, --    dec(9,2)      Last Year's Sales - the total
                               --                  amount of sales made to the
                               --                  customer last year.
arcuTermsCd  	    = 029, --    char(5)       Payment Terms Code - valid
    values
                               --                  are in the opCode table.
arcuTaxableFl       = 030, --    char(1)       Taxable Flag - indicates if
    the
                               --                  customer is subject to tax
                               --                  charges. Y = yes, N = no
    arcuPriceAdjCd      = 031, --    char(2)       Price Adjustment Code - if
--                  numeric, it is a partial key?
                               to
--                  the ic_prod_line table?; if
                               it is
--                  alphabetic, it is a key to
                               the
                               --                  op_ptab? table.
arcuFaxPhone        = 032, --    char(17)      Phone - formatted as
    999-999-9999
--                  XXXX where XXXX is an
                               extension.
    arcuFedId           = 033, --    char(16)      Federal Id - the customer's
                               --                  federal indentifier.
    arcuCreatedDt       = 034, --    date          Date Created - the date the
                               --                  customer was added to the A/R
                               --                  sub-system.
    arcuMaxBal          = 035, --    dec(9,2)     ?Maximum Balance - the highest
--                  balance the customer has had
                               to
                               --                  date.
arcuShipViaCd       = 036, --    char(5)       Ship Via Code - the default
    ship
--                  via code for the customer.
                               Valid
                               --                  values can be found in the
                               --                  ar_code tables.
    arcuFobCd           = 037, --    char(5)       Freight on Board Code - the
--                  default freight on board code
                               for
--                  the customer. Valid values
                               can be
                               --                  found in the arCode table.
	arcuEmail			= 038, --	 Char(50)	   Customer's email address or blank.

	arcuElecInv			= 039  --	 Char(1)	   Does customer allow email invoice
							   --				   faxed invoiced E = email, F = fax
							   --				   N = neither.
--- Initialize ---
global sequence arcuInit
    arcuInit= repeat("",arcuLength)
    arcuInit[arcuCoNbr]           = 1
    arcuInit[arcuCustNbr]         = 0
    arcuInit[arcuSlsmnNbr]		  = "999"
    arcuInit[arcuLstInvDt]        = {0,0,0}
    arcuInit[arcuLstInvAmt]       = 0
    arcuInit[arcuLstPayDt]        = {0,0,0}
    arcuInit[arcuLstPayAmt]       = 0
    arcuInit[arcuYtdSales]        = 0
    arcuInit[arcuInvPdCt]         = 0
    arcuInit[arcuAvgPayDays]      = 0
    arcuInit[arcuCurrBal]         = 0
    arcuInit[arcuCrLimit]         = 0
    arcuInit[arcuLstYrSales]      = 0
    arcuInit[arcuCreatedDt]       = {0,0,0}
    arcuInit[arcuMaxBal]          = 0
	arcuInit[arcuBillCustNbr]	  = 0
	arcuInit[arcuCustCl]		  = 1
	arcuInit[arcuFinanceChg]	  = "N"
	arcuInit[arcuTaxableFl]		  = "N"
	arcuInit[arcuElecInv]		  = "N"
	arcuInit[arcuStmtFl]		  = "Y"
-- end include     arcustomer.e
--------------------------------------------------------------------------------
Bill Reed wrote:
> 
> 
>   People have been saying that Euphoria should be more "C" like, or
>   more "OOP" like.  Euphoria has unique features that set it apart from
>   C or OOP, and make it flexible, but in different ways.
> 
>   Instead of trying to make Euphoria fit into a C mold or OOP mold,
>   take advantage of the unique features of Euphoria.
> 
>   sequences are structures, but not like C.  They are just as flexible,
>   perhaps even more so, since it is easier to add to or change what
>   a sequence is.
> 
>   A sequence can be just a string, "ABC", or a structure:
> }}}
<eucode>
>   a = {
>        "ABC",            -- string
>        123,              -- integer or atom
>        {"XYZ", 456}      -- another sequence
>       }
> 

>    Referencing these members can be done with constants, like
> 
> }}}
<eucode>
>    constant NAME  = 1, AMT  = 2, DESC = 3,
>             DNAME = 1, DAMT = 2
> 
>    a[NAME]           ("ABC")
> 
>    or
>    a[DESC]           (  {"XYZ", 456}  )
>    a[DESC][DNAME]    ("XYZ")
>    a[DESC][DAMT]     (456)
> </eucode>
{{{

> 
>    C has Public and Private functions.  Euphoria can have them too,
>    but in different ways.
> 
>    See the following include and program to see what I mean.  I hope
>    this can stimulate some discussion as to using Euphoria in a more
>    structured way.
> 
> 
>   ====================================================================
>   ==  Member banking.e                                              ==
>   ====================================================================
> }}}
<eucode>
> 
>   --*----------------------------------------------------------------*
>   --*  banking.e             bank account program                    *
>   --*                                                                *
>   --*    Public                                                      *
>   --*      function  BankProgram                                     *
>   --*                                                                *
>   --*    Private (or member functions)                               *
>   --*      function  CreateAcct                                      *
>   --*      function  Withdrawal                                      *
>   --*      function  Deposit                                         *
>   --*      procedure Balance                                         *
>   --*                                                                *
>   --*  example of account:                                           *
>   --*                                                                *
>   --*  a = {015505, "John Smith", 12000.15}                          *
>   --*  a[1] = acctno                                                 *
>   --*  a[2] = acctname                                               *
>   --*  a[3] = balance                                                *
>   --*----------------------------------------------------------------*
> 
> global constant
>     acctno   = 1,
>     acctname = 2,
>     balance  = 3,
>     blank_acct = {0, "", 0}
> 
> function CreateAcct()               -- Private function returns account
>   sequence User_account
> 
>   User_account           = blank_acct
>   User_account[acctno]   = 111000              -- assign next account #
>   User_account[acctname] = prompt_string("Enter name : ")
> 
>   return User_account
> 
> end function
> 
> function Withdrawal(sequence account, atom amount)  -- Private function
>   account[balance] -= amount
> 
>   return account
> 
> end function
> 
> function Deposit(sequence account, atom amount)    -- Private function
>   account[balance] += amount
> 
>   return account
> 
> end function
> 
> procedure Balance(sequence account)                -- Private procedure
>   printf(1, "account : %d  %s  Balance : %.2f\n", {account[acctno],
>                                                    account[acctname],
>                                                    account[balance]})
> 
> end procedure
> 
> global function BankProgram(sequence parms)
>   --*----------------------------------------------------------------*
>   --*  Public because it is global                                   *
>   --*----------------------------------------------------------------*
> 
>   sequence command, User_account, ret_account
>   atom amount
> 
>   --*----------------------------------------------------------------*
>   --*  parms[1] = command                                            *
>   --*  parms[2] = account (optional when creating new account)       *
>   --*  parms[3] = optional amount                                    *
>   --*  parms[4]... optional and expandable                           *
>   --*----------------------------------------------------------------*
> 
>   command  = parms[1]
> 
>   if    equal(command, "new") then
>     ret_account  = CreateAcct()
>   elsif equal(command, "Balance") then
>     User_account = parms[2]
>     Balance(User_account)
>     ret_account  = {}
>   elsif equal(command, "Deposit") then
>     User_account = parms[2]
>     amount       = parms[3]
>     ret_account  = Deposit(User_account, amount)
>   elsif equal(command, "Withdrawal") then
>     User_account = parms[2]
>     amount       = parms[3]
>     ret_account  = Withdrawal(User_account, amount)
>   else
>     puts(1, "Unknown command\n")
>     return {}
>   end if
> 
>   return ret_account
> 
> end function
> </eucode>
{{{

> 
>   ====================================================================
>   ==  end of Member banking.e                                       ==
>   ====================================================================
> 
> 
>   ====================================================================
>   ==                main program:                                   ==
>   ====================================================================
> }}}
<eucode>
> 
>   include get.e
>   include graphics.e
>   include banking.e
> 
>   sequence myAccount, null_status
> 
>   text_color(WHITE) bk_color(BLUE)
>   clear_screen()
> 
>   myAccount   = BankProgram({"new"})
>   myAccount   = BankProgram({"Deposit",    myAccount, 12000.00})
>   myAccount   = BankProgram({"Withdrawal", myAccount, 150.00})
>   null_status = BankProgram({"Balance",    myAccount})
> 
> </eucode>
{{{

> 
>   Other functions and features can be added from this basic
>   framework.  Features such as checking for overdraft status, adding
>   extra fees, crediting or debiting accounts, etc.

new topic     » goto parent     » topic index » view message » categorize

8. Re: Euphoria vs. C and OOP

CChris wrote:
> 
> Bill Reed wrote:

> >   ====================================================================
> >   ==  Member banking.e                                              ==
> >   ====================================================================
> > }}}
<eucode>
> > 
> >   --*----------------------------------------------------------------*
> >   --*  banking.e             bank account program                    *
> >   --*                                                                *
> >   --*    Public                                                      *
> >   --*      function  BankProgram                                     *
> >   --*                                                                *
> >   --*    Private (or member functions)                               *
> >   --*      function  CreateAcct                                      *
> >   --*      function  Withdrawal                                      *
> >   --*      function  Deposit                                         *
> >   --*      procedure Balance                                         *
> >   --*                                                                *
> >   --*  example of account:                                           *
> >   --*                                                                *
> >   --*  a = {015505, "John Smith", 12000.15}                          *
> >   --*  a[1] = acctno                                                 *
> >   --*  a[2] = acctname                                               *
> >   --*  a[3] = balance                                                *
> >   --*----------------------------------------------------------------*
> > 
> > global constant
> >     acctno   = 1,
> >     acctname = 2,
> >     balance  = 3,
> >     blank_acct = {0, "", 0}
> > 
> > function CreateAcct()               -- Private function returns account
> >   sequence User_account
> > 
> >   User_account           = blank_acct
> >   User_account[acctno]   = 111000              -- assign next account #
> >   User_account[acctname] = prompt_string("Enter name : ")
> > 
> >   return User_account
> > 
> > end function
> > 
> > function Withdrawal(sequence account, atom amount)  -- Private function
> >   account[balance] -= amount
> > 
> >   return account
> > 
> > end function
> > 
> > function Deposit(sequence account, atom amount)    -- Private function
> >   account[balance] += amount
> > 
> >   return account
> > 
> > end function
> > 
> > procedure Balance(sequence account)                -- Private procedure
> >   printf(1, "account : %d  %s  Balance : %.2f\n", {account[acctno],
> >                                                    account[acctname],
> >                                                    account[balance]})
> > 
> > end procedure
> > 
> > global function BankProgram(sequence parms)
> >   --*----------------------------------------------------------------*
> >   --*  Public because it is global                                   *
> >   --*----------------------------------------------------------------*
> > 
> >   sequence command, User_account, ret_account
> >   atom amount
> > 
> >   --*----------------------------------------------------------------*
> >   --*  parms[1] = command                                            *
> >   --*  parms[2] = account (optional when creating new account)       *
> >   --*  parms[3] = optional amount                                    *
> >   --*  parms[4]... optional and expandable                           *
> >   --*----------------------------------------------------------------*
> > 
> >   command  = parms[1]
> > 
> >   if    equal(command, "new") then
> >     ret_account  = CreateAcct()
> >   elsif equal(command, "Balance") then
> >     User_account = parms[2]
> >     Balance(User_account)
> >     ret_account  = {}
> >   elsif equal(command, "Deposit") then
> >     User_account = parms[2]
> >     amount       = parms[3]
> >     ret_account  = Deposit(User_account, amount)
> >   elsif equal(command, "Withdrawal") then
> >     User_account = parms[2]
> >     amount       = parms[3]
> >     ret_account  = Withdrawal(User_account, amount)
> >   else
> >     puts(1, "Unknown command\n")
> >     return {}
> >   end if
> > 
> >   return ret_account
> > 
> > end function
> > </eucode>
{{{

> > 
> >   ====================================================================
> >   ==  end of Member banking.e                                       ==
> >   ====================================================================
> > 
> > 
> >   ====================================================================
> >   ==                main program:                                   ==
> >   ====================================================================
> > }}}
<eucode>
> > 
> >   include get.e
> >   include graphics.e
> >   include banking.e
> > 
> >   sequence myAccount, null_status
> > 
> >   text_color(WHITE) bk_color(BLUE)
> >   clear_screen()
> > 
> >   myAccount   = BankProgram({"new"})
> >   myAccount   = BankProgram({"Deposit",    myAccount, 12000.00})
> >   myAccount   = BankProgram({"Withdrawal", myAccount, 150.00})
> >   null_status = BankProgram({"Balance",    myAccount})
> > 
> > </eucode>
{{{

> > 
> >   Other functions and features can be added from this basic
> >   framework.  Features such as checking for overdraft status, adding
> >   extra fees, crediting or debiting accounts, etc.
> 
> This is the sort of hack you are unfortunately saddled with when using the 
> language. Removing this sort of global namespace pollution is a priority 
> issue IMHO.
> If only because, once you have defined a constant "balance" to number the 
> relevant field in your sequence, you can no longer have another "structure"
> 
> use the same name, as the field index name must be global. This makes no 
> sense.
> 
> CChris

For example, The above program written using structured sequences and PBR
is not only simpler, but introduces only a single id (account)
into the global namespace!
--*----------------------------------------------------------------*
   --*  banking.e             bank account program                    *
   --*                                                                *
   --*    Public structures
--*       sequence account                                         *         
                                            *
   --*                                                                *
--*    Public operations (or member functions)                     *         
          *
   --*      function  Init                                            *
   --*      function  Withdrawal                                      *
   --*      function  Deposit                                         *
   --*      procedure Balance                                         *
   --*                                                                *
   --*----------------------------------------------------------------*
 
 
   public sequence account is
       atom balance
       integer acctno
       sequence name
   end sequence

   public function account.Init()
       account.acct_no = 111000
       account.name = prompt_string("Enter name : ")
       account.balance = 0
   end function
	      
   public procedure account.Deposit(atom amount)
       account.balance += amount
   end procedure

   public procedure account.Withdrawal(atom amount)
       account.balance -= amount
   end procedure
						   
   public procedure account.Balance()
       printf(1, "account : %d  %s  Balance : %.2f\n",
                  {account.acctno, account.name, account.balance})
   end procedure

   ====================================================================
   ==  end of Member banking.e                                       ==
   ====================================================================


   ====================================================================
   ==                main program:                                   ==
   ====================================================================
  
   include get.e
   include graphics.e
   include banking.e
 
   account myAccount
 
   text_color(WHITE) bk_color(BLUE)
   clear_screen()

   myAccount.Init()
   myAccount.Deposit(12000.00)
   myAccount.Withdrawal(150.00)
   myAccount.Balance()


KtB

new topic     » goto parent     » topic index » view message » categorize

9. Re: Euphoria vs. C and OOP

don cole wrote:
> 
> jacques deschênes wrote:
> > 
> > I agree with you Bill, Euphoria should stay euphoria, not becoming,
> > c++,java or whatever of the same.
> > 
> > Your exemple is a good one, but the use of strings for commands would
> > slow down the execution a bit. Global constants could be defined instead for
> > commands.
> > 
> > Improvement to euphoria should stick to simple guidelines:
> > - minimize typing effort
> > - reduce name conflict (improvement to namespaces)
> > - reduce scope of variables (related to namespaces)
> > 
> > My yesterday suggestions stick to those guidelines and I agree with Jason
> > concerning an enum decleration because it would reduce typing in accessing
> > sequence elements by defining constants.
> > 
> > regards,
> > Jacques Deschênes
> 
> So you want to change:
> 
> }}}
<eucode>
> 
> sequence holiday
> 
> holiday="christmas" 
> 
> </eucode>
{{{

> 
> to
> 
> }}}
<eucode>
> 
> sequence holiday."christmas"
> 
> </eucode>
{{{

> 
> For the point of saving typing. Is this correct?
> Would holiday be changed later by 
> 
> holiday="easter"
>  Or would another period be needed.
> 
> holiday."easter"?
> 
> Don Cole

Hi Don

OOP is one of the most horriblest (?) and over hyped aspects of programming I've
come across over the last few years - I struggled with Delphi for years until
I came across Euphoria (no disrespect to Matt et al - I have the utmost
respect for their grasp of Euphoria and OOP in order to implement it.)

Euphoria doesn't need it (IMHO)

The above example is relatively simple though (I hope!)

Holiday is an object

Holiday.text would be a property of that object, so you could say

Holiday.text = "Christmas"

and later

Holiday.text = "Easter"

Holiday could also have another property called date, so

Holiday.date = "25/12/2009"

Holiday could also have function associated with, so

Holiday.print - could print out all the other Holiday properties.

Also, each property could have another prperty associated with it

so

Holiday.date.print would print out the date

And so on.

Get a free copy of delphi from somehere if you want to experiment, but to
my mind, I just got unnecessarily bogged down with classes and properties -
Euphoria was like a dream in comparison. As far as I'm concerned, all the talk
of
properities and classes etc, and defining variables should all be add ons, 
and not a requirement for using euphoria.

I'm not saying don't progress, just don't change the base.

Chris

new topic     » goto parent     » topic index » view message » categorize

10. Re: Euphoria vs. C and OOP

George Walters wrote:

BTW, when using the series.e library, this can also written as ...

include series.e
global constant
     arcu                = next_number(0),
     arcuCoNbr           = next_number(arcu),
     arcuCustNbr         = next_number(arcu),
     arcuCustNm          = next_number(arcu),
     arcuAddr1           = next_number(arcu),
     arcuAddr2           = next_number(arcu),
     arcuCity            = next_number(arcu),
     arcuSt              = next_number(arcu),
     arcuZip             = next_number(arcu),
     arcuPhone           = next_number(arcu),
     arcuContact1Nm      = next_number(arcu),
     arcuContact2Nm      = next_number(arcu),
     arcuSlsmnNbr        = next_number(arcu),
     arcuBillCustNbr     = next_number(arcu),
     arcuCustCl          = next_number(arcu),
     arcuLstInvDt        = next_number(arcu),
     arcuLstInvAmt       = next_number(arcu),
     arcuLstPayDt        = next_number(arcu),
     arcuLstPayAmt       = next_number(arcu),
     arcuYtdSales        = next_number(arcu),
     arcuInvPdCt         = next_number(arcu),
     arcuAvgPayDays      = next_number(arcu),
     arcuCurrBal         = next_number(arcu),
     arcuStmtFl          = next_number(arcu),
     arcuTaxAuthCd       = next_number(arcu),
     arcuFinanceChg      = next_number(arcu),
     arcuCustCatCd       = next_number(arcu),
     arcuCrLimit         = next_number(arcu),
     arcuLstYrSales      = next_number(arcu),
     arcuTermsCd  	 = next_number(arcu),
     arcuTaxableFl       = next_number(arcu),
     arcuPriceAdjCd      = next_number(arcu),
     arcuFaxPhone        = next_number(arcu),
     arcuFedId           = next_number(arcu),
     arcuCreatedDt       = next_number(arcu),
     arcuMaxBal          = next_number(arcu),
     arcuShipViaCd       = next_number(arcu),
     arcuFobCd           = next_number(arcu),
     arcuEmail		 = next_number(arcu),
     arcuElecInv	 = next_number(arcu),
     arcuLength	    	 = current_number(arcu) 


Thus making it easier to add, delete, and rearrange fields.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

new topic     » goto parent     » topic index » view message » categorize

11. Re: Euphoria vs. C and OOP

CChris wrote:
> 
> Bill Reed wrote:
> > 
> > 
> >   People have been saying that Euphoria should be more "C" like, or
> >   more "OOP" like.  Euphoria has unique features that set it apart from
> >   C or OOP, and make it flexible, but in different ways.
> > 
> >   Instead of trying to make Euphoria fit into a C mold or OOP mold,
> >   take advantage of the unique features of Euphoria.
> > 
> >   sequences are structures, but not like C.  They are just as flexible,
> >   perhaps even more so, since it is easier to add to or change what
> >   a sequence is.
> > 
> >   A sequence can be just a string, "ABC", or a structure:
> > }}}
<eucode>
> >   a = {
> >        "ABC",            -- string
> >        123,              -- integer or atom
> >        {"XYZ", 456}      -- another sequence
> >       }
> > </eucode>
{{{

> >    Referencing these members can be done with constants, like
> > 
> > }}}
<eucode>
> >    constant NAME  = 1, AMT  = 2, DESC = 3,
> >             DNAME = 1, DAMT = 2
> > 
> >    a[NAME]           ("ABC")
> > 
> >    or
> >    a[DESC]           (  {"XYZ", 456}  )
> >    a[DESC][DNAME]    ("XYZ")
> >    a[DESC][DAMT]     (456)
> > </eucode>
{{{

> > 
> >    C has Public and Private functions.  Euphoria can have them too,
> >    but in different ways.
> > 
> >    See the following include and program to see what I mean.  I hope
> >    this can stimulate some discussion as to using Euphoria in a more
> >    structured way.
> > 
> > 
> >   ====================================================================
> >   ==  Member banking.e                                              ==
> >   ====================================================================
> > }}}
<eucode>
> > 
> >   --*----------------------------------------------------------------*
> >   --*  banking.e             bank account program                    *
> >   --*                                                                *
> >   --*    Public                                                      *
> >   --*      function  BankProgram                                     *
> >   --*                                                                *
> >   --*    Private (or member functions)                               *
> >   --*      function  CreateAcct                                      *
> >   --*      function  Withdrawal                                      *
> >   --*      function  Deposit                                         *
> >   --*      procedure Balance                                         *
> >   --*                                                                *
> >   --*  example of account:                                           *
> >   --*                                                                *
> >   --*  a = {015505, "John Smith", 12000.15}                          *
> >   --*  a[1] = acctno                                                 *
> >   --*  a[2] = acctname                                               *
> >   --*  a[3] = balance                                                *
> >   --*----------------------------------------------------------------*
> > 
> > global constant
> >     acctno   = 1,
> >     acctname = 2,
> >     balance  = 3,
> >     blank_acct = {0, "", 0}
> > 
> > function CreateAcct()               -- Private function returns account
> >   sequence User_account
> > 
> >   User_account           = blank_acct
> >   User_account[acctno]   = 111000              -- assign next account #
> >   User_account[acctname] = prompt_string("Enter name : ")
> > 
> >   return User_account
> > 
> > end function
> > 
> > function Withdrawal(sequence account, atom amount)  -- Private function
> >   account[balance] -= amount
> > 
> >   return account
> > 
> > end function
> > 
> > function Deposit(sequence account, atom amount)    -- Private function
> >   account[balance] += amount
> > 
> >   return account
> > 
> > end function
> > 
> > procedure Balance(sequence account)                -- Private procedure
> >   printf(1, "account : %d  %s  Balance : %.2f\n", {account[acctno],
> >                                                    account[acctname],
> >                                                    account[balance]})
> > 
> > end procedure
> > 
> > global function BankProgram(sequence parms)
> >   --*----------------------------------------------------------------*
> >   --*  Public because it is global                                   *
> >   --*----------------------------------------------------------------*
> > 
> >   sequence command, User_account, ret_account
> >   atom amount
> > 
> >   --*----------------------------------------------------------------*
> >   --*  parms[1] = command                                            *
> >   --*  parms[2] = account (optional when creating new account)       *
> >   --*  parms[3] = optional amount                                    *
> >   --*  parms[4]... optional and expandable                           *
> >   --*----------------------------------------------------------------*
> > 
> >   command  = parms[1]
> > 
> >   if    equal(command, "new") then
> >     ret_account  = CreateAcct()
> >   elsif equal(command, "Balance") then
> >     User_account = parms[2]
> >     Balance(User_account)
> >     ret_account  = {}
> >   elsif equal(command, "Deposit") then
> >     User_account = parms[2]
> >     amount       = parms[3]
> >     ret_account  = Deposit(User_account, amount)
> >   elsif equal(command, "Withdrawal") then
> >     User_account = parms[2]
> >     amount       = parms[3]
> >     ret_account  = Withdrawal(User_account, amount)
> >   else
> >     puts(1, "Unknown command\n")
> >     return {}
> >   end if
> > 
> >   return ret_account
> > 
> > end function
> > </eucode>
{{{

> > 
> >   ====================================================================
> >   ==  end of Member banking.e                                       ==
> >   ====================================================================
> > 
> > 
> >   ====================================================================
> >   ==                main program:                                   ==
> >   ====================================================================
> > }}}
<eucode>
> > 
> >   include get.e
> >   include graphics.e
> >   include banking.e
> > 
> >   sequence myAccount, null_status
> > 
> >   text_color(WHITE) bk_color(BLUE)
> >   clear_screen()
> > 
> >   myAccount   = BankProgram({"new"})
> >   myAccount   = BankProgram({"Deposit",    myAccount, 12000.00})
> >   myAccount   = BankProgram({"Withdrawal", myAccount, 150.00})
> >   null_status = BankProgram({"Balance",    myAccount})
> > 
> > </eucode>
{{{

> > 
> >   Other functions and features can be added from this basic
> >   framework.  Features such as checking for overdraft status, adding
> >   extra fees, crediting or debiting accounts, etc.
> 
> This is the sort of hack you are unfortunately saddled with when using the 
> language. Removing this sort of global namespace pollution is a priority 
> issue IMHO.
> If only because, once you have defined a constant "balance" to number the 
> relevant field in your sequence, you can no longer have another "structure"
> 
> use the same name, as the field index name must be global. This makes no 
> sense.
> 
> CChris


Hi

Try BlitzBasic - it makes perfect sense there!

I would argue that this was not so much a hack, as a feature of the language - 
it does not detract from using the language, it just requires naming global
variables
a little more carefully. The argument to that would be 'why should we', and 
I would answer 'Whats the problem?' Euphoria is a simple, yet versatile,
language
unique from C, yet changing the 'structure' indexing system to make it more 'C'
like would surely lead to a convergence with C.

Perhaps a new language is needed - 'C' with sequences - could call it Cquence -
and
and let Euphoria wallow in its own unique simplicity.

Chris

new topic     » goto parent     » topic index » view message » categorize

12. Re: Euphoria vs. C and OOP

George Walters wrote:

> This is exactly the way we use EU except that all the table column names are
> unique. Here's a sample table.
> 
>
> --------------------------------------------------------------------------------
> -- include arCustomer.e			         created 03/15/02
> -- dbNames= {"ar", "arCustomer"}
> -- arcu
> -- Key Length: 8
> --
> --		AR Customer
> --
> global constant					-- dec(x,y) defined as tot digits,decimal places
>     arcuLength	    	= 039,
>     arcuCoNbr           = 001, --K1  dec(2,0)      Company Number
>     arcuCustNbr         = 002, --K2  dec(6,0)      Customer Number
>     arcuCustNm          = 003, --    char(40)      Customer Name

It would be better to do something like this:

addDatabase("ar")
addDatabase("arCustomer")

addField("arCustomer","arcuAddr1",25) -- why have field length specs?!
...

addData("arCustomer","arcuAddr1","2900 Independence Pkwy")
...

Not only for reason CChris already stated, but also for ease of development
and management of that data in the future.

An even better better way would be to use a database like EDB.

new topic     » goto parent     » topic index » view message » categorize

13. Re: Euphoria vs. C and OOP

Hi again,

Someone mentioned inheritance and how it causes an undesirable coupling
between program modules and i forgot to get back to comment.

I have noticed this too, where you create one 'class' and then
use that to start a new class that has some features of the old
class, so you end up using much of the old file for the new
class.  The problem comes up when later some time you find out
that the old file had a bug (however small) which means your
new class, AND any new classes that came after it, all have the
same bug!  What a drawback, but i guess that's life.  All of
the files have to be corrected unless you have been able to
use that previous file as an include, in which case you only
have to fix that one file and all the rest (which include that
one) are then also fixed.

I guess it is all part of the search for the ideal program
structure, if there even is such a thing.


Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

new topic     » goto parent     » topic index » view message » categorize

14. Re: Euphoria vs. C and OOP

I never mentioned a dot notation

The only addition would be enum declaration

enum  {first_name, last_name, street, town}

sequence addresse

address = repeat(0,5)

address[first_name] = "Don"
address[last_name] = "Cole"
etc...

this would reduce typing compared to 
constant first_name=1, last_name=2, town=3

and those enum could only be used to access sequence elements

Jacques Deschênes

 
don cole wrote:
> 
> jacques deschênes wrote:
> > 
> > I agree with you Bill, Euphoria should stay euphoria, not becoming,
> > c++,java or whatever of the same.
> > 
> > Your exemple is a good one, but the use of strings for commands would
> > slow down the execution a bit. Global constants could be defined instead for
> > commands.
> > 
> > Improvement to euphoria should stick to simple guidelines:
> > - minimize typing effort
> > - reduce name conflict (improvement to namespaces)
> > - reduce scope of variables (related to namespaces)
> > 
> > My yesterday suggestions stick to those guidelines and I agree with Jason
> > concerning an enum decleration because it would reduce typing in accessing
> > sequence elements by defining constants.
> > 
> > regards,
> > Jacques Deschênes
> 
> So you want to change:
> 
> }}}
<eucode>
> 
> sequence holiday
> 
> holiday="christmas" 
> 
> </eucode>
{{{

> 
> to
> 
> }}}
<eucode>
> 
> sequence holiday."christmas"
> 
> </eucode>
{{{

> 
> For the point of saving typing. Is this correct?
> Would holiday be changed later by 
> 
> holiday="easter"
>  Or would another period be needed.
> 
> holiday."easter"?
> 
> Don Cole

new topic     » goto parent     » topic index » view message » categorize

15. Re: Euphoria vs. C and OOP

jacques deschênes wrote:

> The only addition would be enum declaration
> enum  {first_name, last_name, street, town}
> sequence addresse
> address = repeat(0,5)
> address[first_name] = "Don"
> address[last_name] = "Cole"
> etc...
> this would reduce typing compared to 
> constant first_name=1, last_name=2, town=3
> and those enum could only be used to access sequence elements

Or something like this:

newSequence("addresse")   -- newDatabase
define_elements(          -- define_fields
   "addresse" ,
   {
      "name_first",
      "name_last",
      "street",
      "town"
   }
)

set("addresse","name_first","Don")
set("addresse","name_last","Cole")

That's a simple example and makes the code infinitely flexible.

new topic     » goto parent     » topic index » view message » categorize

16. Re: Euphoria vs. C and OOP

Don't like this!
need string comparison to access sequence elements (slow)

It would be better to adopt something like c struct as in a previous post.


seqtype address
  sequence first_name
  sequence last_name
  sequence street
  sequence town
end seqtype

then first_name, last_name, etc... would be converted to constant ny the 
parser.


address customer

customer[first_name] = "" -- we keep the [] notation instead of dot notation
                          -- not to forget that in euphoria every is a sequence

     

jacques deschênes


c.k.lester wrote:
> 
> Or something like this:
> 
> newSequence("addresse")   -- newDatabase
> define_elements(          -- define_fields
>    "addresse" ,
>    {
>       "name_first",
>       "name_last",
>       "street",
>       "town"
>    }
> )
> 
> set("addresse","name_first","Don")
> set("addresse","name_last","Cole")
> 
> That's a simple example and makes the code infinitely flexible.

new topic     » goto parent     » topic index » view message » categorize

17. Re: Euphoria vs. C and OOP

jacques deschênes wrote:

> Don't like this!
> need string comparison to access sequence elements (slow)

True, you need string comparison, but as far as it being slow... probably
not noticeably so. It would be easy to test, though. Anybody? :)

new topic     » goto parent     » topic index » view message » categorize

18. Re: Euphoria vs. C and OOP

jacques deschênes wrote:
> 
> I never mentioned a dot notation
> 
> The only addition would be enum declaration
> 
> enum  {first_name, last_name, street, town}
> 
> sequence addresse
> 
> address = repeat(0,5)
> 
> address[first_name] = "Don"
> address[last_name] = "Cole"
> etc...
> 
> this would reduce typing compared to 
> constant first_name=1, last_name=2, town=3
> 
> and those enum could only be used to access sequence elements
> 

That's an associative array, right? I'm in!! and throw in a good implementation
of "foreach" to walk through that or *any* array, or list, or sequence. ;))  a la
prochaine...
--
duke
http://www.rootshell.be/~perlster/euphoria/

new topic     » goto parent     » topic index » view message » categorize

19. Re: Euphoria vs. C and OOP

ChrisBurch2 wrote:
> 
> don cole wrote:
> > 
> > jacques deschênes wrote:
> > > 
> > > I agree with you Bill, Euphoria should stay euphoria, not becoming,
> > > c++,java or whatever of the same.
> > > 
> > > Your exemple is a good one, but the use of strings for commands would
> > > slow down the execution a bit. Global constants could be defined instead
> > > for
> > > commands.
> > > 
> > > Improvement to euphoria should stick to simple guidelines:
> > > - minimize typing effort
> > > - reduce name conflict (improvement to namespaces)
> > > - reduce scope of variables (related to namespaces)
> > > 
> > > My yesterday suggestions stick to those guidelines and I agree with Jason
> > > concerning an enum decleration because it would reduce typing in accessing
> > > sequence elements by defining constants.
> > > 
> > > regards,
> > > Jacques Deschênes
> > 
> > So you want to change:
> > 
> > }}}
<eucode>
> > 
> > sequence holiday
> > 
> > holiday="christmas" 
> > 
> > </eucode>
{{{

> > 
> > to
> > 
> > }}}
<eucode>
> > 
> > sequence holiday."christmas"
> > 
> > </eucode>
{{{

> > 
> > For the point of saving typing. Is this correct?
> > Would holiday be changed later by 
> > 
> > holiday="easter"
> >  Or would another period be needed.
> > 
> > holiday."easter"?
> > 
> > Don Cole
> 
> Hi Don
> 
> OOP is one of the most horriblest (?) and over hyped aspects of programming
> I've
> come across over the last few years - I struggled with Delphi for years until
> I came across Euphoria (no disrespect to Matt et al - I have the utmost
> respect for their grasp of Euphoria and OOP in order to implement it.)
> 
> Euphoria doesn't need it (IMHO)
> 
> The above example is relatively simple though (I hope!)
> 
> Holiday is an object
> 
> Holiday.text would be a property of that object, so you could say
> 
> Holiday.text = "Christmas"
> 
> and later
> 
> Holiday.text = "Easter"
> 
> Holiday could also have another property called date, so
> 
> Holiday.date = "25/12/2009"
> 
> Holiday could also have function associated with, so
> 
> Holiday.print - could print out all the other Holiday properties.
> 
> Also, each property could have another prperty associated with it
> 
> so
> 
> Holiday.date.print would print out the date
> 
> And so on.
> 
> Get a free copy of delphi from somehere if you want to experiment, but to
> my mind, I just got unnecessarily bogged down with classes and properties -
> Euphoria was like a dream in comparison. As far as I'm concerned, all the talk
> of
> properities and classes etc, and defining variables should all be add ons, 
> and not a requirement for using euphoria.
> 
> I'm not saying don't progress, just don't change the base.
> 
> Chris

Hello ChrisBurch2,

I would say that I agree that Euphoria is complicated and simple enough for my
 needs. I have never come across any requirements that Euphoria (as is) hasen't
 met. There are may aspects of Euphoria that I have experimented with but never
 really used. Such as multitasking. If someone wants to make a Delphi type library
 to go with Euphoria that is fine with me, although I would probebly never use it.
 I say keep Euphoria thev way it is, Simple. This was my main attraction to it.
 Adding libraies and wrappers for special needs such as 3D animation is fine. But
 leave the basic structure alone.
End of my 2 cents.


Don Cole

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu