1. Euphoria vs. C and OOP
- Posted by Bill Reed <rpfproeu at netscape.net> Jan 04, 2007
- 770 views
- Last edited Jan 05, 2007
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.
2. Re: Euphoria vs. C and OOP
- Posted by Jason Gade <jaygade at yahoo.com> Jan 04, 2007
- 760 views
- Last edited Jan 05, 2007
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.
3. Re: Euphoria vs. C and OOP
- Posted by Al Getz <Xaxo at aol.com> Jan 05, 2007
- 721 views
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."
4. Re: Euphoria vs. C and OOP
- Posted by jacques deschênes <desja at globetrotter.net> Jan 05, 2007
- 713 views
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
5. Re: Euphoria vs. C and OOP
- Posted by don cole <doncole at pacbell.net> Jan 05, 2007
- 744 views
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
6. Re: Euphoria vs. C and OOP
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jan 05, 2007
- 738 views
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
7. Re: Euphoria vs. C and OOP
- Posted by George Walters <gwalters at sc.rr.com> Jan 05, 2007
- 718 views
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.
8. Re: Euphoria vs. C and OOP
- Posted by Karl Bochert <kbochert at copper.net> Jan 05, 2007
- 747 views
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
9. Re: Euphoria vs. C and OOP
- Posted by ChrisBurch2 <crylex at freeuk.co.uk> Jan 05, 2007
- 709 views
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
10. Re: Euphoria vs. C and OOP
- Posted by Derek Parnell <ddparnell at bigpond.com> Jan 05, 2007
- 719 views
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
11. Re: Euphoria vs. C and OOP
- Posted by ChrisBurch2 <crylex at freeuk.co.uk> Jan 05, 2007
- 702 views
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
12. Re: Euphoria vs. C and OOP
- Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
- 743 views
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.
13. Re: Euphoria vs. C and OOP
- Posted by Al Getz <Xaxo at aol.com> Jan 05, 2007
- 730 views
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."
14. Re: Euphoria vs. C and OOP
- Posted by jacques deschênes <desja at globetrotter.net> Jan 05, 2007
- 730 views
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
15. Re: Euphoria vs. C and OOP
- Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
- 713 views
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.
16. Re: Euphoria vs. C and OOP
- Posted by jacques deschênes <desja at globetrotter.net> Jan 05, 2007
- 769 views
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.
17. Re: Euphoria vs. C and OOP
- Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
- 721 views
- Last edited Jan 06, 2007
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? :)
18. Re: Euphoria vs. C and OOP
- Posted by duke normandin <dnormandin at bsdrocksperlrolls.com> Jan 05, 2007
- 740 views
- Last edited Jan 06, 2007
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/
19. Re: Euphoria vs. C and OOP
- Posted by don cole <doncole at pacbell.net> Jan 05, 2007
- 735 views
- Last edited Jan 06, 2007
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