I think when people don't know where to start they need some direction, it's just that these specific platforms can often be the wrong one.
Can Dart/Flutter compile into a client only js-app like React?
intAsJson = querySelector('#intAsJson') as TextAreaElement;
doubleAsJson = querySelector('#doubleAsJson') as TextAreaElement;
boolAsJson = querySelector('#boolAsJson') as TextAreaElement;
stringAsJson = querySelector('#stringAsJson') as TextAreaElement;
listAsJson = querySelector('#listAsJson') as TextAreaElement;
mapAsJson = querySelector('#mapAsJson') as TextAreaElement;document.getElementById("intAsJson");.Log in to the intranet and you'll see the form you need to fill out under your account info section. You'll have to select whether you want the trans flag colors or the traditional rainbow stripes, and you'll also need to solve a simple programming puzzle in Kotlin. Note that your performance in this fun mandatory exercise will be noted on your permanent record.
Faie enough, although I would suggest that if you're worrying about nesting depth, something's gone a bit wrong with the structure, and it's worth decomposing it into more child widgets.
Facebook of all places.
It seems like React strongly preferences explicit references where Flutter has more creative ways with Dart to do implicate references with stuff like keys and parent theme providers,
Theme.of. In React it can get annoying and repetitive to have to copy the same props to child components over and over again.import React from 'react';
import axios from 'axios';
import Strings from './strings.js';
import Theme from 'theme';
const DISPLAY_STORAGE = "StorageKey";
const SEARCH = "search-id";
function RadioButtons(options, storage)
{
const [read, controls] = Strings.StringsFrom(options, storage);
const buttons = controls.map(
([opt, is, set]) => {
return (
<label>
<input type="radio"
name="type"
onChange={set}
checked={is}
value={opt}/>
{opt}
</label>
);
}
);
return [read, buttons];
}
export default function Controls(props)
{
const [display, display_buttons] = RadioButtons(
Object.keys(props.options),
DISPLAY_STORAGE
);
function display_type(data)
{
return props.options[display](data);
}
const area = (
<div id={SEARCH}>
search controls
<form>
{display_buttons}
<input type="text"/>
<button onClick={e => e.preventDefault()}>
Search!
</button>
<Theme.ThemeOptions default_theme={props.theme}/>
</form>
</div>
);
return [display_type, area];
}
Disclaimer: I don't like Python, and it's been a while since I've done desktop/mobile UI stuff. And by "arithmetic calculator" I assume you mean something similar to a basic pocket calculator that does addition, subtraction, division and multiplication, though I think these ideas will work with more complex things as well.
let opStore = new OperationStore()class CalculatorButton extends UIButton {
private OperationStore opStore
private String buttonLabel
private UILabel screen
// Hey, look, it's dependency injection!
func init(OperationStore opStore, UILabel screen, String label) {
this.opStore = opStore
this.label = label
this.screen = screen
}
func onPush() {
this.opStore.pushOperation(label)
screen.setText(screen.getText().append(label))
}
}
let screen = new UILabel("0")
window.addControl(screen)
let button1 = new CalculatorButton(opStore, screen, "1")
window.addControl(button1)
let button2 = new CalculatorButton(opStore, screen, "2")
window.addControl(button2)
…class equalsButton extends CalculatorButton {
func onPush() {
Float total = opStore.doCalculation()
screen.setText(total.toString())
}
}
This was my exact experience learning Golang and having code cluttered with
if err != nil
Counterpoint: global variables are fun and easy and were good enough for assembly programmers, who were the Odin of programming. Anyone who says global variables are bad are Loki-worshipping cultists.
Are you seriously suggesting using global variables in place of locals? What in hell is wrong with you? Are you an unfrozen caveman? Make no mistake, asm programmers used globals this way due to technical limitations, it certainly wasn't by choice. In what world is a global variable more more readable than a nicely scoped local variable? "Where's this variable accessed from?" "Anywhere!" Beyond that, global state is an exceptionally terrible idea in our asynchronous world, and in any modern context globals should be used for constants and scarcely anything else.
Given that your program only has "one UI" it may be reasonable to make the UI a piece of global state. It's probably fine for a simple example like this, but generally I would recommend collecting all of your global UI data into a class, and creating an interface through which to mutate it.
# I haven't used python in like 7 years so YMMV
class CalcState: # holds the state of the calculator
sum = 0
operand = 0
op = ""
hasOperand = False
def AddOp(self, op:str): # pop the previous operation, and add a new operation
match op:
case "+":
pass
case "-":
pass
case "*":
pass
case "/":
pass
case _:
raise ValueError("No such operator")
if self.hasOperand:
self.Calculate()
self.op = op
def AddDigit(self, digit:int): # add a digit to our operand
self.operand = self.operand * 10 + digit
self.hasOperand = True
def Clear(self): # clear the calculator
self.sum = 0
self.operand = 10
self.op = ""
self.hasOperand = False
def Calculate(self): # calculate the result of sum op operand
match self.op:
case "":
self.sum = operand
case "+"
self.sum = self.sum + operand
case "-"
self.sum = self.sum - operand
case "*"
self.sum = self.sum * operand
case "/"
self.sum = self.sum / operand
self.operand = 0
self.hasOperand = False
self.op = ""
def FormatState(self):
if self.op == "" and self.hasOperand:
return str(self.operand)
else:
return str(self.sum) + " " + self.op + " " + str(self.operand)
class ProgramState: # holds the calculator state and the ui components
global calc = CalcState()
global enterButton = Button("Enter", lambda: calc.Calculate()) # psuedocode, I don't know any python gui libs
global clearButton = Button("Clear", lambda: calc.Clear())
global plusButton = Button("+", lambda: calc.AddOp("+"))
global minusButton = Button("-", lambda: calc.AddOp("-"))
#...
global zeroButton = Button("0", lambda: calc.AddDigit(0))
global oneButton = Button("1", lambda: calc.AddDigit(1))
#...
global screen = Label(lambda: calc.FormatState())
# each unit is self contained, the ways in which each unit interacts with the other are clear
# duty is also seperated, CalcState manages the state of the calculator, while ProgramState manages the UICool, I'll play around with this.
In your case you can just subclass your Tkinter application or window class. It's pretty easy:
class MyRoot(Tk):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
# your own shit
Delphi as in the Pascal dialect? Fuck no.
Somehow Delphi is ranked #14 on the TIOBE Index, and even went up from #19 last year, which I think says more about how worthless that index is than how worthwhile a language is to learn.
Lazarus is actually pretty nice and actively developed.